On Fri, Dec 20, 2024 at 05:11:52PM +0200, Kirill A. Shutemov wrote: > On Fri, Dec 20, 2024 at 02:38:09PM +0000, Matthew Wilcox wrote: > > On Fri, Dec 20, 2024 at 01:08:39PM +0200, Kirill A. Shutemov wrote: > > > On Fri, Dec 13, 2024 at 08:55:18AM -0700, Jens Axboe wrote: > > > > Add a folio flag that file IO can use to indicate that the cached IO > > > > being done should be dropped from the page cache upon completion. > > > > > > > > Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> > > > > > > Reviewed-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > > > > > > + David, Vlastimil. > > > > > > I think we should consider converting existing folio_set_reclaim() / > > > SetPageReclaim() users to the new flag. From a quick scan, all of them > > > would benefit from dropping the page after writeback is complete instead > > > of leaving the folio on the LRU. > > > > Ooh, that would be nice. Removes the overloading of PG_reclaim with > > PG_readahead, right? > > Yep. Then ... maybe this series should just coopt the PG_reclaim flag for its purposes? Going through the users: lru_deactivate_file() --------------------- Called due to mapping_try_invalidate() failing to invalidate. Absolutely, get rid of this folio as quickly as possible. pageout() --------- Again, we're trying to get rid of this folio. This time due to memory pressure / reaching the end of the LRU list. Yup, we want it gone. shrink_folio_list() ------------------- Again, end of the LRU (both cases in this function) zswap_writeback_entry() ----------------------- This is exactly the same case that Jens is adding. The swapcache is being used as a staging location, and we want the folio gone as soon as writeback completes.
