On Thu, Jul 27, 2017 at 04:53:48PM -0700, Andrew Morton wrote: > On Thu, 20 Jul 2017 14:45:30 -0400 josef@xxxxxxxxxxxxxx wrote: > > > From: Josef Bacik <jbacik@xxxxxx> > > > > Previously we were using the ratio of the number of lru pages scanned to > > the number of eligible lru pages to determine the number of slab objects > > to scan. The problem with this is that these two things have nothing to > > do with each other, > > "nothing"? > > > so in slab heavy work loads where there is little to > > no page cache we can end up with the pages scanned being a very low > > number. > > In this case the "number of eligible lru pages" will also be low, so > these things do have something to do with each other? > The problem is scanned doesn't correlate to the scanned count we calculate, but rather the pages we're able to actually scan. With almost no page cache we end up with really low scanned counts to "relatively" high lru count, which makes the ratio really really low. Anecdotally we would have 10 million inodes in cache, but the ratios were such that our scan target was like 8k. > > This means that we reclaim next to no slab pages and waste a > > lot of time reclaiming small amounts of space. > > > > Instead use sc->priority in the same way we use it to determine scan > > amounts for the lru's. > > That sounds like a good idea. > > Alternatively did you consider hooking into the vmpressure code (or > hannes's new memdelay code) to determine how hard to scan slab? > Vmpressure requires memcg to be turned on. As for memdelay that might be a good direction in the future, but right now it's just per task. We could probably use it for direct reclaim, but I really want this to make kswapd better so we avoid direct reclaim. If it's expanded to be system wide so we could have an idea of the effect of memory reclaim on the whole system that would tie in nicely here. But for now I think staying consistent with everything else is good enough. Thanks, Josef -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
