Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Wed, Jun 8, 2022 at 12:25 PM Ankur Arora <ankur.a.arora@xxxxxxxxxx> wrote: >> >> But, even on x86, AFAICT gigantic pages could straddle MAX_SECTION_BITS? >> An arch specific clear_huge_page() code could, however handle 1GB pages >> via some kind of static loop around (30 - MAX_SECTION_BITS). > > Even if gigantic pages straddle that area, it simply shouldn't matter. > > The only reason that MAX_SECTION_BITS matters is for the 'struct page *' lookup. > > And the only reason for *that* is because of HIGHMEM. > > So it's all entirely silly and pointless on any sane architecture, I think. > >> We'll need a preemption point there for CONFIG_PREEMPT_VOLUNTARY >> as well, right? > > Ahh, yes. I should have looked at the code, and not just gone by my > "PREEMPT_NONE vs PREEMPT" thing that entirely forgot about how we > split that up. > >> Just one minor point -- seems to me that the choice of nontemporal or >> temporal might have to be based on a hint to clear_huge_page(). > > Quite possibly. But I'd prefer that as a separate "look, this > improves numbers by X%" thing from the whole "let's make the > clear_huge_page() interface at least sane". Makes sense to me. -- ankur
