On Mon, Jun 08, 2026 at 07:40:23PM +0100, Matthew Wilcox wrote: > On Mon, Jun 08, 2026 at 12:09:19PM -0400, Gregory Price wrote: > > On Mon, Jun 08, 2026 at 01:00:17PM +0100, Lorenzo Stoakes wrote: > > > On Mon, Jun 08, 2026 at 04:37:48AM -0400, Michael S. Tsirkin wrote: > > > > > > > > void post_alloc_hook(struct page *page, unsigned int order, gfp_t > > > > gfp_flags, > > > > - unsigned long user_addr); > > > > + bool zeroed, unsigned long user_addr); > > > > > > host_zeroed or something would be more appropriate no? > > > > > > But in general do we need to propagate this around, can't we derive it > > > from > > > the page zeroed flag? > > > > > > It's really confusing as to _which_ zeroing this refers to, it seems the > > > only one relevant here is the VM host zeroing but that's completely > > > non-obvious and now everybody using these functions with the extra param > > > will simply have to happen to know this. > > > > > > If we could find a way to avoid this propagation that'd be ideal. > > > > > > Failing that, making it clear this is _only_ for vm host zeroing would be > > > better, but then maybe we need to think about how we could encode this in > > > some other way, e.g. passing alloc_context perhaps? > > > > > > > This is unaddressed feedback from 3 version ago: > > > > https://lore.kernel.org/linux-mm/agXYbcuQYooG74pb@gourry-fedora-PF4VCD3F/ > > > > We can infer all of this from snapshotted page flags and propogate those > > around. This is infinitely more useful than just a single flag being > > pulled out into a boolean, and more extensible. > > > > void > > post_alloc_hook(struct page *page, usigned int order, gfp_t gfp_flags, > > uint64_t pg_alloc_flags, unsigned long user_addr); > > > > ^^^ page_alloc.c internal falgs only > > > > Once the allocator gets a page it wants to return, it can take a snapshot > > of the flags at that point, and then doodle all over the flags as it > > goes through the page setup prior to return (include the post hook). > > > > Haven't seen a reason why this shouldn't be done this way. > > I'd tuned out this awful series since it'd become apparent that my > feedback wasn't going to be taken seriously.
Sorry about that. > Good to know I shouldn't > take it personally because he does it to you too. > > I think it's apparent that Michael has no understanding of the MM. It's a bit of an overstatement but I'm more of a networking guy, yes. What I freely admit I don't understand is why I have to refactor all of mm first. > So we should start again with the architecture. Let's look at the > problem that he's trying to solve: > > - The hypervisor has zeroed the memory that it passes to the MM > - But the MM then zeroes it again before passing it to userspace. > - We want to avoid this > > Let's make sure that's the actual problem before going any further. > Because I do have a design that will satisfy that without doing this > insane level of invasive change, but if that's not the problem, there's > no point wasting my time writing it up. Yes that's exactly the problem I was trying to solve. Early RFC versions didn't do this invasive change: https://lore.kernel.org/lkml/[email protected]/ But I was asked to refactor mm first and implement the optimization second. Sure, glad to hear what the design is. -- MST
