From: Johannes Weiner <hannes@cmpxchg.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Nhat Pham <nphamcs@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] cachestat: implement cachestat syscall
Date: Mon, 21 Nov 2022 10:55:46 -0500 [thread overview]
Message-ID: <Y3ufgkdmGcYlgQwj@cmpxchg.org> (raw)
In-Reply-To: <Y3uPHYX6HxYuE4LX@bfoster>
On Mon, Nov 21, 2022 at 09:45:49AM -0500, Brian Foster wrote:
> On Tue, Nov 15, 2022 at 10:29:00AM -0800, Nhat Pham wrote:
> > Implement a new syscall that queries cache state of a file and
> > summarizes the number of cached pages, number of dirty pages, number of
> > pages marked for writeback, number of (recently) evicted pages, etc. in
> > a given range.
> >
> > NAME
> > cachestat - query the page cache status of a file.
> >
> > SYNOPSIS
> > #include <sys/mman.h>
> >
> > struct cachestat {
> > unsigned long nr_cache;
> > unsigned long nr_dirty;
> > unsigned long nr_writeback;
> > unsigned long nr_evicted;
> > unsigned long nr_recently_evicted;
> > };
> >
> > int cachestat(unsigned int fd, off_t off, size_t len,
> > struct cachestat *cstat);
> >
>
> Do you have a strong use case for a user specified range vs. just
> checking the entire file? If not, have you considered whether it might
> be worth expanding statx() to include this data? That call is already
> designed to include "extended" file status and avoids the need for a new
> syscall. For example, the fields could be added individually with
> multiple flags, or the entire struct tied to a new STATX_CACHE flag or
> some such.
Whole-file stats are only useful for data that is structured in
directory trees. It doesn't work for structured files. For example,
understanding (and subsequently advising/influencing) the readahead
and dirty flushing in certain sections of a larger database file.
Fadvise/madvise/sync_file_range etc. give the user the ability to
influence cache behavior in sub-ranges, so it makes sense to also
allow querying at that granularity.
> > DESCRIPTION
> > cachestat() queries the number of cached pages, number of dirty
> > pages, number of pages marked for writeback, number of (recently)
> > evicted pages, in the bytes range given by `off` and `len`.
> >
> > These values are returned in a cachestat struct, whose address is
> > given by the `cstat` argument.
> >
> > The `off` argument must be a non-negative integers, If `off` + `len`
> > >= `off`, the queried range is [`off`, `off` + `len`]. Otherwise, we
> > will query in the range from `off` to the end of the file.
> >
>
> (off + len < off) is an error condition on some (most?) other syscalls.
> At least some calls (i.e. fadvise(), sync_file_range()) use len == 0 to
> explicitly specify "to EOF."
Good point, it would make sense to stick to that precedent.
next prev parent reply other threads:[~2022-11-21 15:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 18:28 [RFC][PATCH 0/4] cachestat: a new syscall for page cache state of files Nhat Pham
2022-11-15 18:28 ` [PATCH 1/4] workingset: fix confusion around eviction vs refault container Nhat Pham
2022-11-15 18:28 ` [PATCH 2/4] workingset: refactor LRU refault to expose refault recency check Nhat Pham
2022-11-16 7:02 ` kernel test robot
2022-11-15 18:29 ` [PATCH 3/4] cachestat: implement cachestat syscall Nhat Pham
2022-11-16 5:51 ` kernel test robot
2022-11-16 7:02 ` kernel test robot
2022-11-16 11:55 ` kernel test robot
2022-11-21 14:45 ` Brian Foster
2022-11-21 15:55 ` Johannes Weiner [this message]
2022-11-15 18:29 ` [PATCH 4/4] selftests: Add selftests for cachestat Nhat Pham
2022-11-16 23:18 ` [RFC][PATCH 0/4] cachestat: a new syscall for page cache state of files Nhat Pham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y3ufgkdmGcYlgQwj@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=bfoster@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox