archive mirror
 help / color / mirror / Atom feed
Subject: [PATCH 0/2][V3] slab and general reclaim improvements
Date: Thu, 20 Jul 2017 14:45:29 -0400	[thread overview]
Message-ID: <> (raw)

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

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


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

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.


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

             reply	other threads:[~2017-07-20 18:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20 18:45 josef [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).