On 09.03.22 23:07, Linus Torvalds wrote: > On Wed, Mar 9, 2022 at 12:50 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: >> >> We're always running out of page flags. Here's an attempt to free one >> up for the next time somebody wants one. > > Ugh. This is too ugly for words. > > I wouldn't mind something along the conceptual lines of "these bits > are only used for this type", but I think it would need to be much > more organized and explicit, not this kind of randomness. > > For example, quite a few of the page bits really only make sense for > the "page cache and anonymous pages" kind. > > I think this includes some really fundamental bits like the lock bit > (and the associated waiters bit), along with a lot of the "owner" aka > "this can be used by the filesystem" bits. > > I think it _also_ includes all the LRU and workingset bits etc. > > So if we consider that kind of case the "normal" case, the not-normal > case is likely (a) slab, (b) reserved pages and (c) zspages., > > Which is pretty close to your "xyzzy" bit (I think you came to the > same list of "slab or reserved" conclusion because of the fundamental > issues above), but my point is that I think this approach is > acceptable if we make it much less random, and make it a lot more > explicit and thought through. > > And we'd probably need to actually *verify* that we don't do things > like lock (or LRU) those non-normal pages. > Looking at isolate_movable_page(), I think we can easily end up locking random pages temporarily. And especially non-lru page migration makes use of it as well. Personally, I'd not try restricting PG_lock and PG_waiter for specific page types, it IMHO a way to generic infrastructure. Other page flags are different and we already reuse them in different context: e.g., reusing PG_uptodate for buddy pages via PG_reported. -- Thanks, David / dhildenb
