On Mon, Jun 08, 2026 at 04:30:46PM -0400, Michael S. Tsirkin wrote:
> >
> > Please consider that this is arguably the most fundamental interface in
> > in all of mm/. All we're doing is going through the process of figuring
> > out what changes here are reasonable while trying to meet your goal.
> >
> > ~Gregory
>
> I don't mind discarding all of this and doing something else completely,
> but I dislike it that multiple people are apparently now angry that I
I wouldn't say anyone is angry, I think most folks are tripping on the
complexity of the set - which has increased (at the request of others).
> don't address all the contradictory comments at the same time.
Such is life in mm/ :] - it's hard to known the entire state machine,
and sometimes the contradictions aren't even wrong.
> I thought just sending a patchset to show how the result looks like
> is easier than arguing about architecture, and would be helpful.
>
Notice: When folks argue implementation, they largely agree the
end goal is useful. I haven't seen anyone say your problem isn't
real or that it shouldn't be addressed - just opinions on a particular
path forward (which is utterly normal here).
Getting the right incantation of an API is really hard when the
API being changes is something that underpins the entire kernel.
> I'm not pushing any of the mm rework, I was asked to do it,
> myself I just want the ridiculously effective optimization in there.
>
As Lorenzo, David, and Matthew have said, the focus of the patch set
does seem to have become unweildy (in part at the request of folks
asking something be done differently).
What needs to be done now is to break it up into some pull-ahead
sets that are easier to review. Having a brief RFC doc that lays out
the set of patches might help clarify the confusion going on here,
especially as new folks come in to ask "What's all this about?".
As a start:
1) the user_addr and zeroing piece seems like a discrete
improvement worthy of its own set - aside from end goal.
This is needed by your patch set, but was requested to
try to push us towards a more reasonable pattern for
folio_zero_user().
2) There are a handful of patches that seem able to pull-ahead
(some of the mempolicy stuff), either as prep work for #1 or
just on their own.
Some of these patches seem like latent bugs that aren't hit by
current users, but do seem to be doing something subtly wrong?
3) the final virtio piece seems like it should be entirely separate
once the core pieces are done.
It's not uncommon for core changes like this to take multiple prepatory
sets over many major versions before the final feature lands.
~Gregory
