From: Rik van Riel <riel@redhat.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-mm@kvack.org, hannes@cmpxchg.org, kernel-team@fb.com
Subject: Re: [PATCH][RFC] mm: make kswapd try harder to keep active pages in cache
Date: Wed, 03 May 2017 15:20:13 -0400 [thread overview]
Message-ID: <1493839213.20270.17.camel@redhat.com> (raw)
In-Reply-To: <20170503183814.GA11572@destiny>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
On Wed, 2017-05-03 at 14:38 -0400, Josef Bacik wrote:
>
>
> > > + if (nr_inactive > total_high_wmark && nr_inactive >
> > > nr_slab)
> > > + skip_slab = true;
> >
> > I worry that this may be a little too aggressive,
> > and result in the slab cache growing much larger
> > than it should be on some systems.
> >
> > I wonder if it may make more sense to have the
> > aggressiveness of slab scanning depend on the
> > ratio of inactive to reclaimable slab pages, rather
> > than having a hard cut-off like this?
> >
>
> So I originally had a thing that kept track of the rate of change of
> inactive vs
> slab between kswapd runs, but this worked fine so I figured simpler
> was better.
> Keep in mind that we only skip slab the first loop through, so if we
> fail to
> free enough on the inactive list the first time through then we start
> evicting
> slab as well. The idea is (and my testing bore this out) that with
> the new size
> ratio way of shrinking slab we would sometimes be over zealous and
> evict slab
> that we were actively using, even though we had reclaimed plenty of
> pages from
> our inactive list to satisfy our sc->nr_to_reclaim.
My worry is that, since we try to keep the active to
inactive ratio about equal for file pages, many systems
could end up with equal amounts of active file pages,
inactive file pages, and reclaimable slab.
That could not be a gigantic waste of memory for many
workloads, but it could also exacerbate the "reclaim
slab objects forever without freeing any memory" problem
once we do need the memory for something else later on.
> I could probably change the ratio in the sc->inactive_only case to be
> based on
> the slab to inactive ratio and see how that turns out, I'll get that
> wired up
> and let you know how it goes. Thanks,
Looking forward to it.
I am glad to see this problem being attacked :)
--
All rights reversed
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2017-05-03 19:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 21:27 Josef Bacik
2017-05-03 18:24 ` Rik van Riel
2017-05-03 18:38 ` Josef Bacik
2017-05-03 19:20 ` Rik van Riel [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1493839213.20270.17.camel@redhat.com \
--to=riel@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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