[PATCHSET,v6,0/12] Uncached buffered IO

Message

Jens Axboe Dec. 3, 2024, 3:31 p.m. UTC

Hi,

5 years ago I posted patches adding support for RWF_UNCACHED, as a way
to do buffered IO that isn't page cache persistent. The approach back
then was to have private pages for IO, and then get rid of them once IO
was done. But that then runs into all the issues that O_DIRECT has, in
terms of synchronizing with the page cache.

So here's a new approach to the same concent, but using the page cache
as synchronization. That makes RWF_UNCACHED less special, in that it's
just page cache IO, except it prunes the ranges once IO is completed.

Why do this, you may ask? The tldr is that device speeds are only
getting faster, while reclaim is not. Doing normal buffered IO can be
very unpredictable, and suck up a lot of resources on the reclaim side.
This leads people to use O_DIRECT as a work-around, which has its own
set of restrictions in terms of size, offset, and length of IO. It's
also inherently synchronous, and now you need async IO as well. While
the latter isn't necessarily a big problem as we have good options
available there, it also should not be a requirement when all you want
to do is read or write some data without caching.

Even on desktop type systems, a normal NVMe device can fill the entire
page cache in seconds. On the big system I used for testing, there's a
lot more RAM, but also a lot more devices. As can be seen in some of the
results in the following patches, you can still fill RAM in seconds even
when there's 1TB of it. Hence this problem isn't solely a "big
hyperscaler system" issue, it's common across the board.

Common for both reads and writes with RWF_UNCACHED is that they use the
page cache for IO. Reads work just like a normal buffered read would,
with the only exception being that the touched ranges will get pruned
after data has been copied. For writes, the ranges will get writeback
kicked off before the syscall returns, and then writeback completion
will prune the range. Hence writes aren't synchronous, and it's easy to
pipeline writes using RWF_UNCACHED. Folios that aren't instantiated by
RWF_UNCACHED IO are left untouched. This means you that uncached IO
will take advantage of the page cache for uptodate data, but not leave
anything it instantiated/created in cache.

File systems need to support this. The patches add support for the
generic filemap helpers, and for iomap. Then ext4 and XFS are marked as
supporting it. The last patch adds support for btrfs as well, lightly
tested. The read side is already done by filemap, only the write side
needs a bit of help. The amount of code here is really trivial, and the
only reason the fs opt-in is necessary is to have an RWF_UNCACHED IO
return -EOPNOTSUPP just in case the fs doesn't use either the generic
paths or iomap. Adding "support" to other file systems should be
trivial, most of the time just a one-liner adding FOP_UNCACHED to the
fop_flags in the file_operations struct.

Performance results are in patch 8 for reads and patch 10 for writes,
with the tldr being that I see about a 65% improvement in performance
for both, with fully predictable IO times. CPU reduction is substantial
as well, with no kswapd activity at all for reclaim when using uncached
IO.

Using it from applications is trivial - just set RWF_UNCACHED for the
read or write, using pwritev2(2) or preadv2(2). For io_uring, same
thing, just set RWF_UNCACHED in sqe->rw_flags for a buffered read/write
operation. And that's it.

Patches 1..7 are just prep patches, and should have no functional
changes at all. Patch 8 adds support for the filemap path for
RWF_UNCACHED reads, patch 11 adds support for filemap RWF_UNCACHED
writes. In the below mentioned branch, there are then patches to
adopt uncached reads and writes for ext4, xfs, and btrfs.

Passes full xfstests and fsx overnight runs, no issues observed. That
includes the vm running the testing also using RWF_UNCACHED on the host.
I'll post fsstress and fsx patches for RWF_UNCACHED separately. As far
as I'm concerned, no further work needs doing here.

And git tree for the patches is here:

https://git.kernel.dk/cgit/linux/log/?h=buffered-uncached.8

 include/linux/fs.h             |  21 +++++-
 include/linux/page-flags.h     |   5 ++
 include/linux/pagemap.h        |  14 ++++
 include/trace/events/mmflags.h |   3 +-
 include/uapi/linux/fs.h        |   6 +-
 mm/filemap.c                   | 114 +++++++++++++++++++++++++++++----
 mm/readahead.c                 |  22 +++++--
 mm/swap.c                      |   2 +
 mm/truncate.c                  |  35 ++++++----
 9 files changed, 187 insertions(+), 35 deletions(-)

Since v5
- Skip invalidation in filemap_uncached_read() if the folio is dirty
  as well, retaining the uncached setting for later cleaning to do
  the actual invalidation.
- Use the same trylock approach in read invalidation as the writeback
  invalidation does.
- Swap order of patches 10 and 11 to fix a bisection issue.
- Split core mm changes and fs series patches. Once the generic side
  has been approved, I'll send out the fs series separately.
- Rebase on 6.13-rc1

Comments

Christoph Lameter (Ampere) Dec. 3, 2024, 6:23 p.m. UTC | #1

On Tue, 3 Dec 2024, Jens Axboe wrote:

>
> So here's a new approach to the same concent, but using the page cache
> as synchronization. That makes RWF_UNCACHED less special, in that it's
> just page cache IO, except it prunes the ranges once IO is completed.


Great idea and someting that is really important these days.

However, one nit that I have is the use of the term "uncached" for a
folio/page. An uncached "page frame" refers to a page frame that requires
accesses not  going through the cpu cache. I.e. device mappings. This is
an established mm/cpu term as far as I can tell.

So maybe be a bit more specific about which cache this is?

PAGE_CACHE_UNCACHED?

or use a different term. It is cached after all but only for a brief
period. So this may be a "TEMPORAL_PAGE" or so? (Similar to the x86
"non-temporal" stores).

Jens Axboe Dec. 3, 2024, 9:06 p.m. UTC | #2

On 12/3/24 11:23 AM, Christoph Lameter (Ampere) wrote:
> On Tue, 3 Dec 2024, Jens Axboe wrote:
> 
>>
>> So here's a new approach to the same concent, but using the page cache
>> as synchronization. That makes RWF_UNCACHED less special, in that it's
>> just page cache IO, except it prunes the ranges once IO is completed.
> 
> 
> Great idea and someting that is really important these days.
> 
> However, one nit that I have is the use of the term "uncached" for a
> folio/page. An uncached "page frame" refers to a page frame that requires
> accesses not  going through the cpu cache. I.e. device mappings. This is
> an established mm/cpu term as far as I can tell.
> 
> So maybe be a bit more specific about which cache this is?
> 
> PAGE_CACHE_UNCACHED?
> 
> or use a different term. It is cached after all but only for a brief
> period. So this may be a "TEMPORAL_PAGE" or so? (Similar to the x86
> "non-temporal" stores).

I actually did consider using some form of temporal, as it's the only
other name I liked. But I do think cached_uncached becomes pretty
unwieldy. Which is why I just stuck with uncached. Yes I know it means
different things in different circles, but probably mostly an overlap
with deeper technical things like that. An honestly almost impossible to
avoid overlap these days, everything has been used already :-)

IOW, I think uncached is probably still the most descriptive thing out
there, even if I'm certainly open to entertaining other names. Just not
anything yet that has really resonated with me.

Christoph Lameter (Ampere) Dec. 3, 2024, 10:16 p.m. UTC | #3

On Tue, 3 Dec 2024, Jens Axboe wrote:

> I actually did consider using some form of temporal, as it's the only
> other name I liked. But I do think cached_uncached becomes pretty
> unwieldy. Which is why I just stuck with uncached. Yes I know it means
> different things in different circles, but probably mostly an overlap
> with deeper technical things like that. An honestly almost impossible to
> avoid overlap these days, everything has been used already :-)
>
> IOW, I think uncached is probably still the most descriptive thing out
> there, even if I'm certainly open to entertaining other names. Just not
> anything yet that has really resonated with me.

How about calling this a "transitory" page? It means fleeting, not
persistent and I think we have not used that term with a page/folio yet.

Jens Axboe Dec. 3, 2024, 10:41 p.m. UTC | #4

On 12/3/24 3:16 PM, Christoph Lameter (Ampere) wrote:
> On Tue, 3 Dec 2024, Jens Axboe wrote:
> 
>> I actually did consider using some form of temporal, as it's the only
>> other name I liked. But I do think cached_uncached becomes pretty
>> unwieldy. Which is why I just stuck with uncached. Yes I know it means
>> different things in different circles, but probably mostly an overlap
>> with deeper technical things like that. An honestly almost impossible to
>> avoid overlap these days, everything has been used already :-)
>>
>> IOW, I think uncached is probably still the most descriptive thing out
>> there, even if I'm certainly open to entertaining other names. Just not
>> anything yet that has really resonated with me.
> 
> How about calling this a "transitory" page? It means fleeting, not
> persistent and I think we have not used that term with a page/folio yet.

I also hit the thesaurus ;-)

I'm honestly not too worried about the internal name, as developers can
figure that out. It's more about presenting an external name that sys
developers will not need a lot of explaining to know what it's about.
And something that isn't too long. BRIEFLY_CACHED? TRANSIENT_CACHE?

Dunno, I keep going back to uncached as it's pretty easy to grok!

Darrick J. Wong Dec. 4, 2024, 5:52 a.m. UTC | #5

On Tue, Dec 03, 2024 at 03:41:53PM -0700, Jens Axboe wrote:
> On 12/3/24 3:16 PM, Christoph Lameter (Ampere) wrote:
> > On Tue, 3 Dec 2024, Jens Axboe wrote:
> > 
> >> I actually did consider using some form of temporal, as it's the only
> >> other name I liked. But I do think cached_uncached becomes pretty
> >> unwieldy. Which is why I just stuck with uncached. Yes I know it means
> >> different things in different circles, but probably mostly an overlap
> >> with deeper technical things like that. An honestly almost impossible to
> >> avoid overlap these days, everything has been used already :-)
> >>
> >> IOW, I think uncached is probably still the most descriptive thing out
> >> there, even if I'm certainly open to entertaining other names. Just not
> >> anything yet that has really resonated with me.
> > 
> > How about calling this a "transitory" page? It means fleeting, not
> > persistent and I think we have not used that term with a page/folio yet.
> 
> I also hit the thesaurus ;-)
> 
> I'm honestly not too worried about the internal name, as developers can
> figure that out. It's more about presenting an external name that sys
> developers will not need a lot of explaining to know what it's about.
> And something that isn't too long. BRIEFLY_CACHED? TRANSIENT_CACHE?
> 
> Dunno, I keep going back to uncached as it's pretty easy to grok!

<shrug> RWF_DONTCACHE, to match {I,DCACHE}_DONTCACHE ? ;)

They sound pretty similar ("load this so I can do something with it,
evict it immediately if possible") though I wouldn't rely on people
outside the kernel being familiar with the existing dontcaches.

--D

> -- 
> Jens Axboe
> 
>

Jens Axboe Dec. 4, 2024, 4:36 p.m. UTC | #6

On 12/3/24 10:52 PM, Darrick J. Wong wrote:
> On Tue, Dec 03, 2024 at 03:41:53PM -0700, Jens Axboe wrote:
>> On 12/3/24 3:16 PM, Christoph Lameter (Ampere) wrote:
>>> On Tue, 3 Dec 2024, Jens Axboe wrote:
>>>
>>>> I actually did consider using some form of temporal, as it's the only
>>>> other name I liked. But I do think cached_uncached becomes pretty
>>>> unwieldy. Which is why I just stuck with uncached. Yes I know it means
>>>> different things in different circles, but probably mostly an overlap
>>>> with deeper technical things like that. An honestly almost impossible to
>>>> avoid overlap these days, everything has been used already :-)
>>>>
>>>> IOW, I think uncached is probably still the most descriptive thing out
>>>> there, even if I'm certainly open to entertaining other names. Just not
>>>> anything yet that has really resonated with me.
>>>
>>> How about calling this a "transitory" page? It means fleeting, not
>>> persistent and I think we have not used that term with a page/folio yet.
>>
>> I also hit the thesaurus ;-)
>>
>> I'm honestly not too worried about the internal name, as developers can
>> figure that out. It's more about presenting an external name that sys
>> developers will not need a lot of explaining to know what it's about.
>> And something that isn't too long. BRIEFLY_CACHED? TRANSIENT_CACHE?
>>
>> Dunno, I keep going back to uncached as it's pretty easy to grok!
> 
> <shrug> RWF_DONTCACHE, to match {I,DCACHE}_DONTCACHE ? ;)
> 
> They sound pretty similar ("load this so I can do something with it,
> evict it immediately if possible") though I wouldn't rely on people
> outside the kernel being familiar with the existing dontcaches.

Naming is hard! Most people do seem to grok what uncached means, when
I've shopped it around. The fact that it does use the page cache is
pretty irrelevant, that's more of an implementation detail to solve
various issues around competing users of it. That it doesn't persist is
the important bit, and uncached does seem to relay that pretty nicely.