From: Nick Piggin <piggin@cyberone.com.au>
To: Chris Wedgwood <cw@f00f.org>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
Linus Torvalds <torvalds@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: Large slab cache in 2.6.1
Date: Sun, 22 Feb 2004 16:52:50 +1100 [thread overview]
Message-ID: <403843B2.5050103@cyberone.com.au> (raw)
In-Reply-To: <20040222054417.GA14775@dingdong.cryptoapps.com>
Chris Wedgwood wrote:
>On Sun, Feb 22, 2004 at 04:37:46PM +1100, Nick Piggin wrote:
>
>
>>Can you upgrade to 2.6.3-mm2? It would be ideal if you could test
>>this patch against that kernel due to the other VM changes.
>>
>
>Sure.
>
>
>>Chris, could you test this too please? Thanks.
>>
>
>I tested this change to a stock 2.6.3 kernel and saw a marginally
>better situation... 650MB in slab instead of 850MB:
>
In your case, this is probably ideal if the system is
not doing much. You now have a reasonable amount of low
memory available.
>
>===== page_alloc.c 1.186 vs edited =====
>--- 1.186/mm/page_alloc.c Wed Feb 18 19:43:04 2004
>+++ edited/page_alloc.c Sat Feb 21 21:05:32 2004
>@@ -764,13 +764,18 @@
>
> EXPORT_SYMBOL(nr_free_pages);
>
>+/*
>+ * return the number of non-highmem pages (we should probably rename
>+ * this function? --cw)
>+ */
> unsigned int nr_used_zone_pages(void)
> {
> unsigned int pages = 0;
> struct zone *zone;
>
> for_each_zone(zone)
>- pages += zone->nr_active + zone->nr_inactive;
>+ if (!is_highmem(zone))
>+ pages += zone->nr_active + zone->nr_inactive;
>
> return pages;
> }
>
>
>I'll test -mm2 with your patch shortly.
>
>
My patch will be functionally the same as yours so you'll be
mainly testing the other VM changes (which isn't a bad thing).
Thanks.
>
>>@@ -145,7 +145,7 @@ static int shrink_slab(unsigned long sca
>> if (down_trylock(&shrinker_sem))
>> return 0;
>>
>>- pages = nr_used_zone_pages();
>>+ pages = nr_lowmem_lru_pages();
>>
>
>Cool. I think renaming this i a good idea.
>
>
Yep.
>>-unsigned int nr_used_zone_pages(void)
>>+unsigned int nr_lowmem_lru_pages(void)
>> {
>>+ pg_data_t *pgdat;
>> unsigned int pages = 0;
>>- struct zone *zone;
>>
>>- for_each_zone(zone)
>>- pages += zone->nr_active + zone->nr_inactive;
>>+ for_each_pgdat(pgdat) {
>>+ int i;
>>+ for (i = 0; i < ZONE_HIGHMEM; i++) {
>>+ struct zone *zone = pgdat->node_zones + i;
>>+ pages += zone->nr_active + zone->nr_inactive;
>>+ }
>>+ }
>>
>
>Why not just check is_highmem(zone) here?
>
>
Why indeed? Easier to read vs a tiny bit faster. It isn't
really a fast path, so your version is probably better.
>>-extern unsigned int nr_used_zone_pages(void);
>>+extern unsigned int nr_lowmem_lru_pages(void);
>>
>
>Since shrink_slab() is the only consumer of this why not move the
>function to vmscan.c just above shrink_slab()?
>
>
Might as well I suppose. I'll incorporate your suggestions if
it tests well and I end up sending it off to Andrew.
next prev parent reply other threads:[~2004-02-22 5:52 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-22 0:50 Large slab cache in 2.6.1 Mike Fedyk
2004-02-22 1:09 ` Mike Fedyk
2004-02-22 1:20 ` William Lee Irwin III
2004-02-22 2:03 ` Mike Fedyk
2004-02-22 2:17 ` William Lee Irwin III
2004-02-22 2:38 ` Nick Piggin
2004-02-22 2:46 ` William Lee Irwin III
2004-02-22 2:40 ` Mike Fedyk
2004-02-22 2:58 ` Nick Piggin
2004-02-22 2:33 ` Nick Piggin
2004-02-22 2:46 ` Nick Piggin
2004-02-22 2:54 ` Nick Piggin
2004-02-22 2:36 ` Chris Wedgwood
2004-02-22 3:03 ` Linus Torvalds
2004-02-22 3:11 ` Chris Wedgwood
2004-02-22 3:28 ` Linus Torvalds
2004-02-22 3:29 ` Chris Wedgwood
2004-02-22 3:31 ` Chris Wedgwood
2004-02-22 4:01 ` Nick Piggin
2004-02-22 4:10 ` Nick Piggin
2004-02-22 4:30 ` Nick Piggin
2004-02-22 4:41 ` Mike Fedyk
2004-02-22 5:37 ` Nick Piggin
2004-02-22 5:44 ` Chris Wedgwood
2004-02-22 5:52 ` Nick Piggin [this message]
2004-02-22 5:50 ` Mike Fedyk
2004-02-22 6:01 ` Nick Piggin
2004-02-22 6:17 ` Andrew Morton
2004-02-22 6:35 ` Nick Piggin
2004-02-22 6:57 ` Andrew Morton
2004-02-22 7:20 ` Nick Piggin
2004-02-22 8:36 ` Chris Wedgwood
2004-02-22 9:13 ` Andrew Morton
2004-02-23 0:16 ` Nick Piggin
2004-02-23 0:26 ` Andrew Morton
2004-02-23 0:34 ` Nick Piggin
2004-02-23 0:46 ` Andrew Morton
2004-02-23 0:54 ` Nick Piggin
2004-02-23 1:00 ` Andrew Morton
2004-02-23 1:06 ` Nick Piggin
2004-02-22 6:45 ` Mike Fedyk
2004-02-22 6:58 ` Nick Piggin
2004-02-22 7:20 ` Mike Fedyk
2004-02-22 6:09 ` Andrew Morton
2004-02-22 17:05 ` Linus Torvalds
2004-02-23 0:29 ` Nick Piggin
2004-02-22 6:15 ` Andrew Morton
2004-02-22 16:08 ` Martin J. Bligh
2004-02-22 17:55 ` Jamie Lokier
2004-02-23 3:45 ` Mike Fedyk
2004-02-22 21:13 ` Dipankar Sarma
2004-02-22 14:03 ` Ed Tomlinson
2004-02-23 2:28 ` Mike Fedyk
2004-02-23 3:33 ` Ed Tomlinson
2004-02-22 3:21 ` Mike Fedyk
-- strict thread matches above, loose matches on Subject: below --
2004-02-22 11:00 Manfred Spraul
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=403843B2.5050103@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfedyk@matchmail.com \
--cc=torvalds@osdl.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