Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux