archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <>
	Josef Bacik <>
Subject: Re: [PATCH 1/2] mm: use sc->priority for slab shrink targets
Date: Thu, 24 Aug 2017 16:08:01 +0900	[thread overview]
Message-ID: <20170824070801.GA20463@bgram> (raw)
In-Reply-To: <>

On Tue, Aug 22, 2017 at 03:35:38PM -0400, wrote:
> From: Josef Bacik <>
> 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, 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.  This means that we reclaim next to no slab pages and waste a
> lot of time reclaiming small amounts of space.

Your answer on the question I asked will help to parse this paragraph.

Quote from previous discussion:
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.

Please add it to the description.

> Instead use sc->priority in the same way we use it to determine scan
> amounts for the lru's.  This generally equates to pages.  Consider the
> following
> slab_pages = (nr_objects * object_size) / PAGE_SIZE
> What we would like to do is
> scan = slab_pages >> sc->priority
> but we don't know the number of slab pages each shrinker controls, only
> the objects.  However say that theoretically we knew how many pages a
> shrinker controlled, we'd still have to convert this to objects, which
> would look like the following
> scan = shrinker_pages >> sc->priority
> scan_objects = (PAGE_SIZE / object_size) * scan
> or written another way
> scan_objects = (shrinker_pages >> sc->priority) *
> 		(PAGE_SIZE / object_size)
> which can thus be written
> scan_objects = ((shrinker_pages * PAGE_SIZE) / object_size) >>
> 		sc->priority
> which is just
> scan_objects = nr_objects >> sc->priority
> We don't need to know exactly how many pages each shrinker represents,
> it's objects are all the information we need.  Making this change allows
> us to place an appropriate amount of pressure on the shrinker pools for
> their relative size.
> Signed-off-by: Josef Bacik <>

Acked-by: Minchan Kim <>

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>

  parent reply	other threads:[~2017-08-24  7:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 19:35 [PATCH 1/2] mm: use sc->priority for slab shrink targets josef
2017-08-22 19:35 ` [PATCH 2/2][v2] mm: make kswapd try harder to keep active pages in cache josef
2017-08-24  7:22   ` Minchan Kim
2017-08-24  7:08 ` Minchan Kim [this message]
2017-08-24 14:29 ` [PATCH 1/2] mm: use sc->priority for slab shrink targets Andrey Ryabinin
2017-08-24 14:49   ` Josef Bacik
2017-08-24 22:15     ` Dave Chinner
2017-08-24 22:45       ` Josef Bacik
2017-08-25  1:40         ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
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

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 \
    --in-reply-to=20170824070801.GA20463@bgram \ \ \ \ \ \ \ \ \ \ \

* 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).