On Wed 19-04-23 10:48:03, Marcelo Tosatti wrote: > On Wed, Apr 19, 2023 at 02:24:01PM +0200, Frederic Weisbecker wrote: [...] > > 2) Run critical code > > 3) Optionally do something once you're done > > > > If vmstat is going to be the only thing to wait for on 1), then the remote > > solution looks good enough (although I leave that to -mm guys as I'm too > > clueless about those matters), > > I am mostly clueless too, but i don't see a problem with the proposed > patch (and no one has pointed any problem either). I really hate to repeat myself again. The biggest pushback has been on a) justification and b) single purpose solution which is very likely incomplete. For a) we are getting the story piece by piece which doesn't speed up the process. You are proposing a non-trivial change to an already convoluted code so having a solid justification is something that shouldn't be all that surprising. b) is what concerns me more though. There are other per-cpu specific things going on that require some regular flushing. Just to mention another one that your group has been brought up was the memcg pcp caches. Again with a non-trivial proposal to deal with that problem [1]. It has turned out that we can do a simpler thing [2]. I do not think it is a stretch to expect that similar things will pop out every now and then and rather than dealing with each one in its own way it kinda makes sense to come up with a more general concept so that all those cases can be handled at a single place at least. All I hear about that is that the code of those special applications would need to be changed to use that. Well, true but is that bar so impractical that we are going to grow kernel complexity and therefore a maintenance burden? Everything for a very specialized workloads? [1] http://lkml.kernel.org/r/20221102020243.522358-1-leobras@xxxxxxxxxx [2] http://lkml.kernel.org/r/20230317134448.11082-1-mhocko@xxxxxxxxxx -- Michal Hocko SUSE Labs
