[Sorry I was offline] On Mon 19-12-22 14:42:52, Andrew Morton wrote: > On Sat, 17 Dec 2022 10:57:06 +0100 Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > I think it's a bit premature to revert at this stage. Possibly we can > > > get to the desired end state by modifying the existing code. Possibly > > > we can get to the desired end state by reverting this and by adding > > > something new. > > > > Sure if we can converge to a proper implementation during the rc phase > > then it would be ok. I cannot speak for others but at least for me > > upcoming 2 weeks would be mostly offline so I cannot really contribute > > much. A revert would be much more easier from the coordination POV IMHO. > > > > Also I do not think there is any strong reason to rush this in. I do not > > really see any major problems to have this extension in 6.2 > > I'll queue the revert in mm-unstable with a plan to merge it upstream > around the -rc5 timeframe if there hasn't been resolution. Thanks! I do not really think we need to rush node based reclaim and better have a reasonable and more futureproof interface. > Please check Mina's issues with this revert's current changelog and > perhaps send along a revised one. Yes, I believe, I have addressed all the feedback but I am open to alter the wording of course. The biggest concern by Mina IIRC was that the nr_reclaimed reporting has been a pre-existing problem. And I agree with that. The thing is that this doesn't matter without node specification because the memory gets reclaimed even if the reported value is over accounted. With nodemask specification the value becomes bogus if no demotion nodes are specified because no memory gets reclaimed potentially while the success is still reported. Mina has tried to address that but I am not convinced the fix is actually future proof. This really requires more discussion. -- Michal Hocko SUSE Labs
