From: Chris Wedgwood <cw@f00f.org>
To: Nick Piggin <piggin@cyberone.com.au>
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: Sat, 21 Feb 2004 21:44:17 -0800 [thread overview]
Message-ID: <20040222054417.GA14775@dingdong.cryptoapps.com> (raw)
In-Reply-To: <4038402A.4030708@cyberone.com.au>
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:
===== 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.
>
> @@ -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.
> -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?
> -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()?
next prev parent reply other threads:[~2004-02-22 5:44 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 [this message]
2004-02-22 5:52 ` Nick Piggin
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=20040222054417.GA14775@dingdong.cryptoapps.com \
--to=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfedyk@matchmail.com \
--cc=piggin@cyberone.com.au \
--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