| Message ID | 20241203153232.92224-2-axboe@kernel.dk (mailing list archive) |
|---|---|
| Headers | show |
| Series | Uncached buffered IO | expand |
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).
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.
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.
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!
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 > >
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.
On Tue, Dec 03, 2024 at 08:31:36AM -0700, Jens Axboe wrote: > 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 Oh good, I much prefer browsing git branches these days. :) * mm/filemap: change filemap_create_folio() to take a struct kiocb * mm/readahead: add folio allocation helper * mm: add PG_uncached page flag * mm/readahead: add readahead_control->uncached member * mm/filemap: use page_cache_sync_ra() to kick off read-ahead * mm/truncate: add folio_unmap_invalidate() helper The mm patches look ok to me, but I think you ought to get at least an ack from willy since they're largely pagecache changes. * fs: add RWF_UNCACHED iocb and FOP_UNCACHED file_operations flag See more detailed reply in the thread. * mm/filemap: add read support for RWF_UNCACHED Looks cleaner now that we don't even unmap the page if it's dirty. * mm/filemap: drop uncached pages when writeback completes * mm/filemap: add filemap_fdatawrite_range_kick() helper * mm/filemap: make buffered writes work with RWF_UNCACHED See more detailed reply in the thread. * mm: add FGP_UNCACHED folio creation flag I appreciate that !UNCACHED callers of __filemap_get_folio now clear the uncached bit if it's set. Now I proceed into the rest of your branch, because I felt like it: * ext4: add RWF_UNCACHED write support (Dunno about the WARN_ON removals in this patch, but this is really Ted's call anyway). * iomap: make buffered writes work with RWF_UNCACHED The commit message references a "iocb_uncached_write" but I don't find any such function in the extended patchset? Otherwise this looks ready to me. Thanks for changing it only to set uncached if we're actually creating a folio, and not just returning one that was already in the pagecache. * xfs: punt uncached write completions to the completion wq Dumb nit: spaces between "IOMAP_F_SHARED|IOMAP_F_UNCACHED" in this patch. * xfs: flag as supporting FOP_UNCACHED Otherwise the xfs changes look ready too. * btrfs: add support for uncached writes * block: support uncached IO Not sure why the definition of bio_dirty_lock gets moved around, but in principle this looks ok to me too. For the whole pile of mm changes (aka patches 1-6,8-10,12), Acked-by: "Darrick J. Wong" <djwong@kernel.org> --D > > 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 > > -- > Jens Axboe > >
On Tue, Dec 03, 2024 at 09:52:41PM -0800, Darrick J. Wong wrote: > <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. FYI, another word for dontcache. uncached just has too many conotations in the kernel context.
On 12/10/24 4:11 AM, Christoph Hellwig wrote: > On Tue, Dec 03, 2024 at 09:52:41PM -0800, Darrick J. Wong wrote: >> <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. > > FYI, another word for dontcache. uncached just has too many conotations > in the kernel context. Sure, we can go with DONTCACHE instead. Only thing I don't like about that is that you can use uncached as a verb and adjective, eg talking about uncached IO. Talking about dontcached IO sounds pretty weird. As I've said previously in this and other threads, I don't feel too strongly about the in-kernel naming, I care more about the exposed name. And uncached does seem to be the most descriptive and most easily understandable by users.
On Thu, 12 Dec 2024, Jens Axboe wrote: > On 12/10/24 4:11 AM, Christoph Hellwig wrote: > > On Tue, Dec 03, 2024 at 09:52:41PM -0800, Darrick J. Wong wrote: > >> <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. > > > > FYI, another word for dontcache. uncached just has too many conotations > > in the kernel context. > > Sure, we can go with DONTCACHE instead. Only thing I don't like about > that is that you can use uncached as a verb and adjective, eg talking > about uncached IO. Talking about dontcached IO sounds pretty weird. > > As I've said previously in this and other threads, I don't feel too > strongly about the in-kernel naming, I care more about the exposed > name. And uncached does seem to be the most descriptive and most > easily understandable by users. The page is cached while the operation is ongoing. "Transitory" would be more accurate and it is a new term that was not used with pages before.
On 12/12/24 9:59 AM, Christoph Lameter (Ampere) wrote: > On Thu, 12 Dec 2024, Jens Axboe wrote: > >> On 12/10/24 4:11 AM, Christoph Hellwig wrote: >>> On Tue, Dec 03, 2024 at 09:52:41PM -0800, Darrick J. Wong wrote: >>>> <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. >>> >>> FYI, another word for dontcache. uncached just has too many conotations >>> in the kernel context. >> >> Sure, we can go with DONTCACHE instead. Only thing I don't like about >> that is that you can use uncached as a verb and adjective, eg talking >> about uncached IO. Talking about dontcached IO sounds pretty weird. >> >> As I've said previously in this and other threads, I don't feel too >> strongly about the in-kernel naming, I care more about the exposed >> name. And uncached does seem to be the most descriptive and most >> easily understandable by users. > > The page is cached while the operation is ongoing. "Transitory" would be > more accurate and it is a new term that was not used with pages before. Like I mentioned earlier, the fact that it's cached for the duration of the operation is more of an implementation detail that developers need not worry about. What's important is that it's not cached AFTER. I still feel UNCACHED is the best description, but I'll change it to DONTCACHE for the next version just to avoid the overlap with other in-kernel uses.
On Thu, Dec 12, 2024 at 12:14:23PM -0700, Jens Axboe wrote: > Like I mentioned earlier, the fact that it's cached for the duration of > the operation is more of an implementation detail that developers need > not worry about. What's important is that it's not cached AFTER. I still > feel UNCACHED is the best description, but I'll change it to DONTCACHE > for the next version just to avoid the overlap with other in-kernel > uses. Regardless of the user API name, I like PG_streaming for the folio flag name.
On 12/12/24 12:35 PM, Matthew Wilcox wrote: > On Thu, Dec 12, 2024 at 12:14:23PM -0700, Jens Axboe wrote: >> Like I mentioned earlier, the fact that it's cached for the duration of >> the operation is more of an implementation detail that developers need >> not worry about. What's important is that it's not cached AFTER. I still >> feel UNCACHED is the best description, but I'll change it to DONTCACHE >> for the next version just to avoid the overlap with other in-kernel >> uses. > > Regardless of the user API name, I like PG_streaming for the folio > flag name. Sure, I can make that change.
On Thu, 12 Dec 2024, Matthew Wilcox wrote: > Regardless of the user API name, I like PG_streaming for the folio > flag name. Streaming I/O seems to be a good name for this ....
On Thu, Dec 12, 2024 at 07:35:28PM +0000, Matthew Wilcox wrote: > On Thu, Dec 12, 2024 at 12:14:23PM -0700, Jens Axboe wrote: > > Like I mentioned earlier, the fact that it's cached for the duration of > > the operation is more of an implementation detail that developers need > > not worry about. What's important is that it's not cached AFTER. I still > > feel UNCACHED is the best description, but I'll change it to DONTCACHE > > for the next version just to avoid the overlap with other in-kernel > > uses. > > Regardless of the user API name, I like PG_streaming for the folio > flag name. If we're throwing names in the ring, I'm partial to PG_dropbehind. It's a term I think has been used to describe this type of behavior before; it juxtaposes nicely with readahead; it plainly names the action of what will happen to the page after the current IO operation against it has completed (i.e. pairs up with PG_reclaim).
On 12/12/24 10:04 PM, Johannes Weiner wrote: > On Thu, Dec 12, 2024 at 07:35:28PM +0000, Matthew Wilcox wrote: >> On Thu, Dec 12, 2024 at 12:14:23PM -0700, Jens Axboe wrote: >>> Like I mentioned earlier, the fact that it's cached for the duration of >>> the operation is more of an implementation detail that developers need >>> not worry about. What's important is that it's not cached AFTER. I still >>> feel UNCACHED is the best description, but I'll change it to DONTCACHE >>> for the next version just to avoid the overlap with other in-kernel >>> uses. >> >> Regardless of the user API name, I like PG_streaming for the folio >> flag name. > > If we're throwing names in the ring, I'm partial to PG_dropbehind. > > It's a term I think has been used to describe this type of behavior > before; it juxtaposes nicely with readahead; it plainly names the > action of what will happen to the page after the current IO operation > against it has completed (i.e. pairs up with PG_reclaim). True, I do think that's a good name for the folio flag. streaming isn't bad, but it's not fully descriptive as the IO may not be streaming at all, depending on the use case. I do remember when we used dropbehind naming in the vm, probably 20 some years ago? If there are no objections to this, I'll change the folio flag to dropbehind. Also looks nicer with the bit operations on the folio, when you have: if (flags & RWF_DONTCACHE) folio_set_dropbehind(folio); rather than: if (flags & RWF_DONTCACHE) folio_set_streaming(folio); and so forth, as the former just intuitively makes sense.