On Wed, Mar 08, 2023 at 12:24:08PM -0800, Yosry Ahmed wrote: > > I tried to come up with something better, but wasn't happy with any of > > the options, either. So I defaulted to just leaving it alone :-) > > > > It's part of the shrinker API and the name hasn't changed since the > > initial git import of the kernel tree. It should be fine, churn-wise. > > Last attempt, just update_reclaim_state() (corresponding to > flush_reclaim_state() below). It doesn't tell a story, but neither > does incrementing a counter in current->reclaim_state. If that doesn't > make you happy I'll give up now and leave it as-is :) This is used in different subsystem shrinkers outside mm/, so the name needs to be correctly namespaced. Please prefix it with the subsystem the function belongs to, at minimum. mm_account_reclaimed_pages() is what is actually being done here. It is self describing and leaves behind no ambiguity as to what is being accounted and why, nor which subsystem the accounting belongs to. It doesn't matter what the internal mm/vmscan structures are called, all we care about is telling the mm infrastructure how many extra pages were freed by the shrinker.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
