From: Nick Piggin <piggin@cyberone.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>, linux-mm@kvack.org
Subject: Re: [PATCH] kswapd shall not sleep during page shortage
Date: Wed, 10 Nov 2004 13:49:57 +1100 [thread overview]
Message-ID: <419181D5.1090308@cyberone.com.au> (raw)
In-Reply-To: <4191675B.3090903@cyberone.com.au>
Nick Piggin wrote:
>
> (*) I'm beginning to think they're due to me accidentally bumping the
> page watermarks when 'fixing' them. I'll check that out presently.
>
>
That's basically it...
2.6.8 and 2.6.10-rc both have the same watermarks (in pages):
-----------
From SysRq+M:
pages_min pages_low pages_high
dma 4 8 12
normal 234 468 702
high 128 256 384
However, 2.6.10-rc has all 0's in its ->protection maps, 2.6.8 looks like:
gfp_dma gfp_normal gfp_high
dma 8 476 732
normal 0 468 724
high 0 0 256
Because 2.6.8 basically keys the entire alloc_pages behaviour off the
->protection map (and look: the diagonal corresponds to pages_low for
each zone).
-----------
Following is the minimum free pages for each zone at which some action
will happen for order-0 (ZONE_NORMAL) allocations:
2.6.8
| GFP_KERNEL | GFP_ATOMIC
allocate immediately | 477 dma, 469 norm | 12 dma, 469 norm
allocate after waking kswapd | 477 dma, 469 norm | 12 dma, 352 norm
allocate after synch reclaim | 477 dma, 469 norm | n/a
2.6.10-rc
| 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
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
Although you can see that, theoretically 2.6.10 has a much better layout
of numbers, and an increased ZONE_NORMAL buffer, 2.6.8's weird ZONE_DMA
handling gives it 4 times the amount of buffer between GFP_KERNEL and
GFP_ATOMIC allocations.
Shall we crank up min_free_kbytes a bit?
We could also compress the watermarks, while increasing pages_min? That
will increase the GFP_ATOMIC buffer as well, without having free memory
run away on us (eg pages_min = 2*x, pages_low = 5*x/2, pages_high = 3*x)?
--
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>
next prev parent reply other threads:[~2004-11-10 2:49 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 [this message]
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
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=419181D5.1090308@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
/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.