Messages in this thread | | | Date | Thu, 3 Nov 2022 18:36:09 +0100 | Subject | Re: mm: delay rmap removal until after TLB flush | From | David Hildenbrand <> |
| |
On 03.11.22 18:09, Linus Torvalds wrote: > 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.
Thanks for the explanation. I brought it up because the generic name somehow felt weird in include/asm-generic/tlb.h. Skimming over the code I'd have expected something like TLB_ENCODE_PAGE_BITS, so making the "very generic" things "very specific" as long as it lives in tlb.h :)
-- Thanks,
David / dhildenb
| |