On Wed, May 29, 2024 at 5:33 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: ... > > > Indeed, if we're open to radical ideas, the LRU sucks. A physical scan > > > is 40x faster: > > > https://lore.kernel.org/linux-mm/ZTc7SHQ4RbPkD3eZ@xxxxxxxxxxxxxxxxxxxx/ > > > > That simulation assumes the page struct has access to information already. > > On the physical CPU level, the access bit is from the PTE. If you scan > > from physical page order, you need to use rmap to find the PTE to > > check the access bit. It is not a simple pfn page order walk. You need > > to scan the PTE first then move the access information into page > > struct. > > We already maintain the dirty bit on the folio when we take a write-fault > for file memory. If we do that for anon memory as well, we don't need > to do an rmap walk at scan time. > The access bit in the PTE is set by the CPU, and in terms of moving the accessed bit into the folio, I think that's already done by MGLRU scanning of PTEs, but the gen number written to the folios is per-lruvec. I can't come up with a scheme Perhaps the idea is to scan through all the folios on a system, instead of evicting folios from each LRU list? As for whether anon folios should behave more similar to file, I think this is an excellent opportunity to reconcile some special handling of anon vs file. Because to me a swap-backed folio writeback mechanism sounds a lot like what "proactive reclaim on anon pages" achieves: not having to wait to reclaim memory.
