On Thu, May 30, 2024 at 6:56 PM Yuanchu Xie <yuanchu@xxxxxxxxxx> wrote: > > 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. That is the point I was trying to make. To get the latest hot and cold information, it needs to scan the PTE access bits. The walk on page struct in pfn order does not able to achieve the same thing. > 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.
