On Tue, Jun 13, 2017 at 02:28:02PM +0900, Minchan Kim wrote: > Hello, > > On Thu, Jun 08, 2017 at 03:19:05PM -0400, josef@xxxxxxxxxxxxxx wrote: > > From: Josef Bacik <jbacik@xxxxxx> > > > > When testing a slab heavy workload I noticed that we often would barely > > reclaim anything at all from slab when kswapd started doing reclaim. > > This is because we use the ratio of nr_scanned / nr_lru to determine how > > much of slab we should reclaim. But in a slab only/mostly workload we > > will not have much page cache to reclaim, and thus our ratio will be > > really low and not at all related to where the memory on the system is. > > I want to understand this clearly. > Why nr_scanned / nr_lru is low if system doesnt' have much page cache? > Could you elaborate it a bit? > Yeah so for example on my freshly booted test box I have this Active: 58840 kB Inactive: 46860 kB Every time we do a get_scan_count() we do this scan = size >> sc->priority where sc->priority starts at DEF_PRIORITY, which is 12. The first loop through reclaim would result in a scan target of 2 pages to 11715 total inactive pages, and 3 pages to 14710 total active pages. This is a really really small target for a system that is entirely slab pages. And this is super optimistic, this assumes we even get to scan these pages. We don't increment sc->nr_scanned unless we 1) isolate the page, which assumes it's not in use, and 2) can lock the page. Under pressure these numbers could probably go down, I'm sure there's some random pages from daemons that aren't actually in use, so the targets get even smaller. We have to get sc->priority down a lot before we start to get to the 1:1 ratio that would even start to be useful for reclaim in this scenario. Add to this that most shrinkable slabs have this idea that their objects have to loop through the LRU twice (no longer icache/dcache as Al took my patch to fix that thankfully) and you end up spending a lot of time looping and reclaiming nothing. Basing it on actual slab usage makes more sense logically and avoids this kind of problem. 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>
