Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 3 Nov 2022 10:09:11 -0700 | Subject | Re: mm: delay rmap removal until after TLB flush |
| |
On Thu, Nov 3, 2022 at 9:54 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > But again, those changes would have made the patch bigger, which I > didn't want at this point (and 'release_pages()' would need that > clean-in-place anyway, unless we changed *that* too and made the whole > page encoding be something widely available).
And just to clarify: this is not just me trying to expand the reach of my patch.
I'd suggest people look at mlock_pagevec(), and realize that LRU_PAGE and NEW_PAGE are both *exactly* the same kind of "encoded_page" bits that TLB_ZAP_RMAP is.
Except the mlock code does *not* show that in the type system, and instead just passes a "struct page **" array around in pvec->pages, and then you'd just better know that "oh, it's not *really* just a page pointer".
So I really think that the "array of encoded page pointers" thing is a generic notion that we *already* have.
It's just that we've done it disgustingly in the past, and I didn't want to do that disgusting thing again.
So I would hope that the nasty things that the mlock code would some day use the same page pointer encoding logic to actually make the whole "this is not a page pointer that you can use directly, it has low bits set for flags" very explicit.
I am *not* sure if then the actual encoded bits would be unified. Probably not - you might have very different and distinct uses of the encode_page() thing where the bits mean different things in different contexts.
Anyway, this is me just explaining the thinking behind it all. The page bit encoding is a very generic thing (well, "very generic" in this case means "has at least one other independent user"), explaining the very generic naming.
But at the same time, the particular _patch_ was meant to be very targeted.
So slightly schizophrenic name choices as a result.
Linus
| |