On Wed, 6 Apr 2022 10:01:30 +1000 Dave Chinner wrote: > On Tue, Apr 05, 2022 at 10:21:53PM +0100, Matthew Wilcox wrote: > > On Tue, Apr 05, 2022 at 01:58:59PM -0700, Yang Shi wrote: > > > Yeah, I agree it actually doesn't make too much sense to return the > > > number of reclaimed objects. Other part of vmscan returns the number > > > of base pages, the sizes of slab objects are varied, it may be much > > > smaller than a page, for example, dentry may be 192 bytes. > > > > From the point of view of vmscan, it only cares about the number of pages > > freed because it's trying to free pages. But from the point of view of > > trying to keep the number of non-useful objects in check, the number of > > objects freed is more important, and it doesn't matter whether we ended > > up freeing any pages because we made memory available for this slab cache. > > Yes and no. If the memory pressure is being placed on this cache, > then freeing any number of objects is a win-win situation - reclaim > makes progress and new allocations don't need to wait for reclaim. > > However, if there is no pressure on this slab cache, then freeing > objects but no actual memory pages is largely wasted reclaim effort. > Freeing those objects does nothing to alleviate the memory shortage, > and the memory freed is not going to be consumed any time soon so > all we've done is fragment the slab cache and require the subsystem > to spend more resources re-populating it. That's a lose-lose. > > We want to select the shrinkers that will result in the former > occurring, not the latter. Looks like we head on the very start point - why is it needed to periodically wake up kswapd without real memory pressure? Hillf
