Re: [PATCH] kswapd shall not sleep during page shortage

Nick Piggin
2004-11-10T02:49:57Z

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)?