linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2][V3] slab and general reclaim improvements
@ 2017-07-20 18:45 josef
  2017-07-20 18:45 ` [PATCH 1/2] mm: use sc->priority for slab shrink targets josef
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: josef @ 2017-07-20 18:45 UTC (permalink / raw)
  To: minchan, linux-mm, hannes, riel, akpm, david, kernel-team

This is a new set of patches to address some slab reclaim issues I observed when
trying to convert btrfs over to a purely slab meta data system.  The problem is
our slab reclaim amounts are based on how page cache scanning goes, which is not
related to how much slab is in use on the system.  This means we waste a lot of
cycles trying to reclaim really small numbers of objects and thus induce a huge
latency hit when we hit memory pressure.

The second patch is to fix another problem I noticed, namely that we will
constantly evict active pages instead of trying to evict shorter lived pages and
objects.  You can run the following test to see the behavior

https://github.com/josefbacik/debug-scripts/blob/master/cache-pressure/cache-pressure.sh

Reading two files that fit nicely into RAM, and then add slab pressure from
fs_mark and you'll see that we will evict both files 3 or 4 times during the
run.  With my patches we don't evict any of the file pages at all, only the slab
pressure.

CHANGES SINCE V2:

After discussions with Minchan and Dave I went back to the drawing board.
Dave's suggestion of shrinker specific callbacks to allow shrinkers to reclaim
at their own rate was intriguing so I did this first.  Unfortunately this fell
apart as I couldn't figure out a scheme to make the reclaim stuff work without
needlessly inducing latency during 'stable' periods.  Without a view of the
whole system it's hard to know when to trigger scanning of active objects
without wasting CPU cycles that aren't actually needed.  We will end up starting
our background thread and scanning objects when in reality our workload would
fit perfectly fine in memory.

Minchan's main complaint of my stuff was that it was too aggressive, and any
attempt to short circuit the aggression would be unfair to other shrinkers.  So
instead use his idea of using sc->priority to determine our scan count.  But
instead of using the traditional ratio, just use scan = nr_objects >>
sc->priority.  This gets us what we do with the LRU, which is scan = pages >>
sc->priority, and gives us an appropriate amount of aggressiveness for slab
reclaim.

I've dropped the other two patches around stopping slab reclaim, and have
changed the slab pressure to be based on sc->priority, which is consistent with
every other LRU on the system, and gives me the same results in my testcases.
Thanks,

Josef

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-07-28 23:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-20 18:45 [PATCH 0/2][V3] slab and general reclaim improvements josef
2017-07-20 18:45 ` [PATCH 1/2] mm: use sc->priority for slab shrink targets josef
2017-07-27 23:53   ` Andrew Morton
2017-07-28 23:52     ` Josef Bacik
2017-07-20 18:45 ` [PATCH 2/2] mm: make kswapd try harder to keep active pages in cache josef
2017-07-27 23:55 ` [PATCH 0/2][V3] slab and general reclaim improvements Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).