All of lore.kernel.org
 help / color / mirror / Atom feed
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()?



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