On Mon, Jun 08, 2026 at 04:53:14PM -0400, Gregory Price wrote: > 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().
What I worry about is people can't agree what api they want. Simply not being an mm maintainer, I don't really have the perspective of what changes are envisioned down the road and so what api makes sense for you guys. I don't mind trying all kind of approaches, but it seems to be past the point where people feel it's costing too much of their time with all of these revisions. > 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? Right. > 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
