On Thu, May 12, 2022 at 2:55 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > The LWN writeup [1] on merging the MGLRU reminded me that I need to send > out a plan for removing page flags that we can do without. Much appreciated. > 1. PG_error. It's basically useless. If the page was read successfully, > PG_uptodate is set. If not, PG_uptodate is clear. The page cache > doesn't use PG_error. Some filesystems do, and we need to transition > them away from using it. > > 2. PG_private. This tells us whether we have anything stored at > page->private. We can just check if page->private is NULL or not. > No need to have this extra bit. Again, there may be some filesystems > that are a bit wonky here, but I'm sure they're fixable. > > 3. PG_mappedtodisk. This is really only used by the buffer cache. > Once the filesystems that use bufferheads have been converted, this can > go away. > > 4. I think I can also consolidate PG_slab and PG_reserved into a "single > bit" (not really, but change the encoding so that effectively they only > take a single bit). > > That gives us 4 bits back, which should relieve the pressure on page flag > bits for a while. I have Thoughts on PG_private_2 and PG_owner_priv_1, > as well as a suspicion that not all combinations of referenced, lru, > active, workingset, reclaim and unevictable are possible, and there > might be scope for a better encoding. But I don't know that we need to > do that work; gaining back 4 bits is already a Big Deal. PG_active, PG_ unevictable and PG_swapbacked seem to be the low hanging fruit among those you mentioned above. They indicate which LRU list a folio is currently on, was deleted from or should be added to. We should be able to use the spare bits in folio->lru for this purpose. WDYT? > I'm slowly doing the PG_private transition as part of the folio work. > For example, eagle eyed reviewers may have spotted that there is no > folio_has_buffers(). Converted code calls folio_buffers() and checks > if it's NULL. Help from filesystem maintainers on removing the uses of > PG_error gratefully appreciated. > > [1] https://lwn.net/Articles/894859/ We'd be very happy to help with testing and reviewing, etc.
