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.
We already have some page flag bits that are only used for those kinds
of odd pages: the page_flags field is used only for zspages, but other
pages can (misuse) that field for PG_buddy/offline/etc. That whole
thing is particularly ugly in how it tries to make sure there are is
no mapcount use of it.
So I do think something like your "xyzzy" bit can work, but I'd really
want it to be a lot more explicit and a lot less random than "let's
encode two special bits this way".
Linus
