From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] vm: kswapd incmin
Date: Mon, 7 Nov 2005 16:43:06 -0200 [thread overview]
Message-ID: <20051107184306.GA18493@logos.cnet> (raw)
In-Reply-To: <436FDE85.9090205@yahoo.com.au>
On Tue, Nov 08, 2005 at 10:08:53AM +1100, Nick Piggin wrote:
> Marcelo Tosatti wrote:
> >Hi Nick,
> >
> >Looks nice, much easier to read than before.
> >
>
> Hi Marcelo,
>
> Thanks! That was one of the main aims.
>
> >One comment: you change the pagecache/slab scanning ratio by moving
> >shrink_slab() outside of the zone loop.
> >
> >This means that for each kswapd iteration will scan "lru_pages"
> >SLAB entries, instead of "lru_pages*NR_ZONES" entries.
> >
> >Can you comment on that?
> >
>
> I believe I have tried to get it right, let me explain. lru_pages
> is just used as the divisor for the ratio between lru scanning
> and slab scanning. So long as it is kept constant across calls to
> shrink_slab, there should be no change in behaviour.
>
> The the nr_scanned variable is the other half of the equation that
> controls slab shrinking. I have changed from:
>
> lru_pages = total_node_lru_pages;
> for each zone in node {
> shrink_zone();
> shrink_slab(zone_scanned, lru_pages);
> }
>
> To:
>
> lru_pages = 0;
> for each zone in node {
> shrink_zone();
> lru_pages += zone_lru_pages;
> }
> shrink_slab(total_zone_scanned, lru_pages);
>
> So the ratio remains basically the same
> [eg. 10/100 + 20/100 + 30/100 = (10+20+30)/100]
>
> 2 reasons for doing this. The first is just efficiency and better
> rounding of the divisions.
>
> The second is that within the for_each_zone loop, we are able to
> set all_unreclaimable without worrying about slab, because the
> final shrink_slab at the end will clear all_unreclaimable if any
> zones have had slab pages freed up.
>
> I believe it generally should result in more consistent reclaim
> across zones, and also matches direct reclaim better.
>
> Hope this made sense,
Yes, makes sense. My reading was not correct.
Sounds great.
prev parent reply other threads:[~2005-11-07 23:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-01 5:18 [PATCH 0/3] better zone and watermark balancing Nick Piggin
2005-11-01 5:19 ` [PATCH 1/3] vm: kswapd incmin Nick Piggin
2005-11-01 5:20 ` [PATCH 2/3] vm: highmem watermarks Nick Piggin
2005-11-01 5:21 ` [PATCH 3/3] vm: writeout watermarks Nick Piggin
2005-11-07 15:33 ` Marcelo Tosatti
2005-11-07 21:13 ` Nikita Danilov
2005-11-07 23:12 ` Nick Piggin
2005-11-07 15:28 ` [PATCH 1/3] vm: kswapd incmin Marcelo Tosatti
2005-11-07 23:08 ` Nick Piggin
2005-11-07 18:43 ` Marcelo Tosatti [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=20051107184306.GA18493@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.