All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Andrew Morton <akpm@osdl.org>, linux-mm@kvack.org
Subject: Re: [PATCH] kswapd shall not sleep during page shortage
Date: Wed, 10 Nov 2004 06:17:33 -0200	[thread overview]
Message-ID: <20041110081733.GG8414@logos.cnet> (raw)
In-Reply-To: <419195F9.4070806@cyberone.com.au>

On Wed, Nov 10, 2004 at 03:15:53PM +1100, Nick Piggin wrote:
> 
> 
> Andrew Morton wrote:
> 
> >Nick Piggin <piggin@cyberone.com.au> wrote:
> >
> >>Make sense?
> >>
> >
> >Hey, you know me - I'll believe anything.
> >
> >Let's take a second look at the numbers when you have a patch.  Please
> >check that we're printing all the relevant info at boot time.
> >
> >
> >
> >
> 
> OK with this patch, this is what the situation looks like:
> 
> without patch:
>      pages_min   pages_low   pages_high
> dma        4          8          12
> normal   234        468         702
> high     128        256         384
> 
> with patch:
>      pages_min   pages_low   pages_high
> dma       17         21          25
> normal   939       1173        1408
> high     128        160         192
> 
> without patch:
>                             | GFP_KERNEL        | GFP_ATOMIC
> allocate immediately         |   9 dma, 469 norm |  9 dma, 469 norm
> allocate after waking kswapd |   5 dma, 234 norm |  3 dma,  88 norm
> allocate after synch reclaim |   5 dma, 234 norm |  n/a
> 
> with patch:
>                             | GFP_KERNEL         | GFP_ATOMIC
> allocate immediately         |  22 dma, 1174 norm | 22 dma, 1174 norm
> allocate after waking kswapd |  18 dma,  940 norm |  6 dma,  440 norm
> allocate after synch reclaim |  18 dma,  940 norm |  n/a
> 
> 
> So the buffer between GFP_KERNEL and GFP_ATOMIC allocations is:
> 
> 2.6.8      | 465 dma, 117 norm, 582 tot = 2328K
> 2.6.10-rc  |   2 dma, 146 norm, 148 tot =  592K
> patch      |  12 dma, 500 norm, 512 tot = 2048K
> 
> Which is getting pretty good.
> 
> 
> kswap starts at:
> 2.6.8     477 dma, 496 norm, 973 total
> 2.6.10-rc   8 dma, 468 norm, 476 total
> patched    17 dma, 939 norm, 956 total
> 
> So in terms of total pages, that's looking similar to 2.6.8.
> 
> I'd respectfully suggest this is a regression (versus 2.6.8, at least),
> and hope it (or something like it) can get included in 2.6.10 after further
> testing?

That looks much better, thanks Nick!

I bet we wont be seeing the failures so often with this in place,
nice analysis.

>  linux-2.6-npiggin/mm/page_alloc.c |   41 +++++++++++++++++++++-----------------
>  1 files changed, 23 insertions(+), 18 deletions(-)
> 
> diff -puN mm/page_alloc.c~mm-restore-atomic-buffer mm/page_alloc.c
> --- linux-2.6/mm/page_alloc.c~mm-restore-atomic-buffer	2004-11-10 15:13:33.000000000 +1100
> +++ linux-2.6-npiggin/mm/page_alloc.c	2004-11-10 14:57:54.000000000 +1100
> @@ -1935,8 +1935,12 @@ static void setup_per_zone_pages_min(voi
>  			                   lowmem_pages;
>  		}
>  
> -		zone->pages_low = zone->pages_min * 2;
> -		zone->pages_high = zone->pages_min * 3;
> +		/*
> +		 * When interpreting these watermarks, just keep in mind that:
> +		 * zone->pages_min == (zone->pages_min * 4) / 4;
> +		 */
> +		zone->pages_low   = (zone->pages_min * 5) / 4;
> +		zone->pages_high  = (zone->pages_min * 6) / 4;
>  		spin_unlock_irqrestore(&zone->lru_lock, flags);
>  	}
>  }
> @@ -1945,24 +1949,25 @@ static void setup_per_zone_pages_min(voi
>   * Initialise min_free_kbytes.
>   *
>   * For small machines we want it small (128k min).  For large machines
> - * we want it large (16MB max).  But it is not linear, because network
> + * we want it large (64MB max).  But it is not linear, because network
>   * bandwidth does not increase linearly with machine size.  We use
>   *
> - *	min_free_kbytes = sqrt(lowmem_kbytes)
> + * 	min_free_kbytes = 4 * sqrt(lowmem_kbytes), for better accuracy:
> + *	min_free_kbytes = sqrt(lowmem_kbytes * 16)
>   *
>   * which yields
>   *
> - * 16MB:	128k
> - * 32MB:	181k
> - * 64MB:	256k
> - * 128MB:	362k
> - * 256MB:	512k
> - * 512MB:	724k
> - * 1024MB:	1024k
> - * 2048MB:	1448k
> - * 4096MB:	2048k
> - * 8192MB:	2896k
> - * 16384MB:	4096k
> + * 16MB:	512k
> + * 32MB:	724k
> + * 64MB:	1024k
> + * 128MB:	1448k
> + * 256MB:	2048k
> + * 512MB:	2896k
> + * 1024MB:	4096k
> + * 2048MB:	5792k
> + * 4096MB:	8192k
> + * 8192MB:	11584k
> + * 16384MB:	16384k
>   */
>  static int __init init_per_zone_pages_min(void)
>  {
> @@ -1970,11 +1975,11 @@ static int __init init_per_zone_pages_mi
>  
>  	lowmem_kbytes = nr_free_buffer_pages() * (PAGE_SIZE >> 10);
>  
> -	min_free_kbytes = int_sqrt(lowmem_kbytes);
> +	min_free_kbytes = int_sqrt(lowmem_kbytes * 16);
>  	if (min_free_kbytes < 128)
>  		min_free_kbytes = 128;
> -	if (min_free_kbytes > 16384)
> -		min_free_kbytes = 16384;
> +	if (min_free_kbytes > 65536)
> +		min_free_kbytes = 65536;
>  	setup_per_zone_pages_min();
>  	setup_per_zone_protection();
>  	return 0;
> 
> _

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

      reply	other threads:[~2004-11-10  8:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-09 16:46 [PATCH] kswapd shall not sleep during page shortage Marcelo Tosatti
2004-11-09 20:19 ` Andrew Morton
2004-11-09 17:41   ` Marcelo Tosatti
2004-11-09 21:33     ` Andrew Morton
2004-11-09 18:26       ` Marcelo Tosatti
2004-11-09 22:22         ` Andrew Morton
2004-11-09 20:31           ` Marcelo Tosatti
2004-11-10  0:28             ` Andrew Morton
2004-11-09 23:16               ` Marcelo Tosatti
2004-11-09 23:34                 ` Marcelo Tosatti
2004-11-10  2:53                 ` Andrew Morton
2004-11-10 18:14               ` Marcelo Tosatti
2004-11-10 22:08                 ` Andrew Morton
2004-11-10  0:56           ` Nick Piggin
2004-11-10  2:49             ` Nick Piggin
2004-11-10  2:56               ` Andrew Morton
2004-11-10  3:12                 ` Nick Piggin
2004-11-10  3:18                   ` Andrew Morton
2004-11-10  3:27                     ` Nick Piggin
2004-11-10  4:15                     ` Nick Piggin
2004-11-10  8:17                       ` 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=20041110081733.GG8414@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=piggin@cyberone.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.