All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: zlang@kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] fsx: add support for RWF_DONTCACHE
Date: Tue, 7 Jan 2025 17:00:24 -0700	[thread overview]
Message-ID: <770d0b93-d61d-4fc0-9649-f9850db11f8b@kernel.dk> (raw)
In-Reply-To: <20250107232240.GT6160@frogsfrogsfrogs>

On 1/7/25 4:22 PM, Darrick J. Wong wrote:
> On Tue, Jan 07, 2025 at 11:24:13AM -0700, Jens Axboe wrote:
>> On 1/7/25 11:19 AM, Darrick J. Wong wrote:
>>> On Tue, Jan 07, 2025 at 09:05:15AM -0700, Jens Axboe wrote:
>>>> Using RWF_DONTCACHE tells the kernel that any page cache instantiated
>>>> by this operation should get pruned once the operation completes. If
>>>> data is in cache prior to the operation it will remain there.
>>>>
>>>> Add ops for testing both the read and write side of this. At startup,
>>>> kernel support for this feature is probed. If support isn't available,
>>>> uncached/dontcache IO is performed as regular buffered IO. If -Z is
>>>> used to turn on O_DIRECT, then uncached/dontcache IO isn't performed.
>>>
>>> Huh.  Does the kernel reject RWF_DONTCACHE for directio?  And, if a
>>
>> It doesn't, it simply ignores it. Not sure why you ask? It's buffered IO
>> after all, falling back to just clearing the flag seems like the most
>> sensible solution here.
> 
> I was curious, because your code does has_dontcache=0 when -Z is used to
> select directio mode.  So I wondered if it that was because the kernel
> would return EOPNOTSUPP for directio + RWF_DONTCACHE? :)

Ah gotcha - no that's not the case, it's just that it doesn't make any
sense to open a file O_DIRECT and then use RWF_DONTCACHE, when it
already shouldn't be cached. Outside of the case you brought up where
we'd want to drop page cache for O_DIRECT that ends up allocating page
cache, but that should be done regardless imho.

> Then I wondered if there was actually a good usecase either for letting
> userspace specify it, or for filesystems to add it for buffered write
> fallback.  At this point I would wager there's a stronger case for
> adding drop-behind automatically because userspace shouldn't have to
> communicate "write this without accessing the page cache, and don't
> leave file contents in the page cache that I already told you not to
> do."

Yeah agree, I think we should just use the same mechanism for O_DIRECT
instantiated page cache, without needing the app setting RWF_DONTCACHE.
O_DIRECT is also slowed down by the existence of page cache, which can
be annoying particularly when you fill a file with O_DIRECT and now have
a bunch of page cache for it.

> Anyway the fstests change satisfies me now so
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

Thanks!

-- 
Jens Axboe

  reply	other threads:[~2025-01-08  0:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07 16:05 [PATCHSET v2 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-07 16:05 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 17:31   ` Darrick J. Wong
2025-01-07 16:05 ` [PATCH 2/2] fsx: " Jens Axboe
2025-01-07 18:19   ` Darrick J. Wong
2025-01-07 18:24     ` Jens Axboe
2025-01-07 23:22       ` Darrick J. Wong
2025-01-08  0:00         ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-01-06 17:48 [PATCHSET 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-06 17:48 ` [PATCH 2/2] fsx: add support for RWF_DONTCACHE Jens Axboe
2025-01-07  2:09   ` Darrick J. Wong
2025-01-07  2:12     ` Jens Axboe

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=770d0b93-d61d-4fc0-9649-f9850db11f8b@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=zlang@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.