linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nhat Pham <nphamcs@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	bfoster@redhat.com, Matthew Wilcox <willy@infradead.org>,
	linux-api@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v8 2/3] cachestat: implement cachestat syscall
Date: Fri, 27 Jan 2023 14:46:28 -0500	[thread overview]
Message-ID: <Y9QqFJUFo1RAbIqP@cmpxchg.org> (raw)
In-Reply-To: <54c8ecbd-1d6e-40f1-af30-7efd04c63a7e@app.fastmail.com>

On Fri, Jan 27, 2023 at 04:46:38PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 26, 2023, at 18:53, Nhat Pham wrote:
> >
> > SYNOPSIS
> >     #include <sys/mman.h>
> >
> >     struct cachestat {
> >         __u64 nr_cache;
> >         __u64 nr_dirty;
> >         __u64 nr_writeback;
> >         __u64 nr_evicted;
> >         __u64 nr_recently_evicted;
> >     };
> >
> >     int cachestat(unsigned int fd, off_t off, size_t len,
> >           unsigned int cstat_version, struct cachestat *cstat,
> >           unsigned int flags);
> 
> Is this "off_t off" argument intentionally limited to the old
> 32-bit type on 32-bit architectures? Unfortunately I fear 
> there are no good options to pass an offset here:
> 
> - if you make it a 32-bit type, this breaks calling it from
>   normal userspace that defines off_t as a 64-bit type
> 
> - if you change it to a 64-bit loff_t, there are three
>   separate calling conventions for 64-bit, 32-bit with
>   aligned register pairs and other 32-bit, plus you
>   exceed the usual limit of six system call arguments

That's a good point, thanks for raising it, Arnd.

> A separate problem may be the cstat_version argument, usually
> we don't use interface versions but instead use a new
> system call number if something changes in an incompatible
> way.

I suppose from a userspace POV, a version argument vs calling a
separate syscall doesn't make much of a difference. So going with
loff_t and dropping cstat_version seems like a sensible way forward.

As an added bonus, versioning the syscall itself means the signature
can change in v2. This allows dropping the unused flags arg for now.

That would leave it at:

  int cachestat(unsigned int, loff_t, size_t len, struct cachestat *cstat);

and should we ever require extensions - new fields, flags - they would
come through a new cachestat2().

Would anybody have objections to that?


  reply	other threads:[~2023-01-27 19:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 17:53 [PATCH v8 0/3] cachestat: a new syscall for page cache state of files Nhat Pham
2023-01-26 17:53 ` [PATCH v8 1/3] workingset: refactor LRU refault to expose refault recency check Nhat Pham
2023-01-26 17:53 ` [PATCH v8 2/3] cachestat: implement cachestat syscall Nhat Pham
2023-01-27 15:46   ` Arnd Bergmann
2023-01-27 19:46     ` Johannes Weiner [this message]
2023-01-27 20:29       ` Arnd Bergmann
2023-01-29 12:11   ` kernel test robot
2023-01-26 17:53 ` [PATCH v8 3/3] selftests: Add selftests for cachestat 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=Y9QqFJUFo1RAbIqP@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bfoster@redhat.com \
    --cc=kernel-team@meta.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=willy@infradead.org \
    /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