Re: [RFC][PATCH 0/8] Critical Page Pool

From: Matthew Dobson
Date: Mon Nov 21 2005 - 00:48:59 EST

Chris Wright wrote:
> * Matthew Dobson (colpatch@xxxxxxxxxx) wrote:
>>/proc/sys/vm/critical_pages: write the number of pages you want to reserve
>>for the critical pool into this file
> How do you size this pool?

Trial and error. If you want networking to survive with no memory other
than the critical pool for 2 minutes, for example, you pick a random value,
block all other allocations (I have a test patch to do this), and send a
boatload of packets at the box. If it OOMs, you need a bigger pool.
Lather, rinse, repeat.

> Allocations are interrupt driven, so how to you
> ensure you're allocating for the cluster network traffic you care about?

On the receive side, you can't. :( You *have* to allocate an skbuff for
the packet, and only a couple levels up the networking 7-layer burrito can
you tell if you can toss the packet as non-critical or keep it. On the
send side, you can create a simple socket flag that tags all that socket's
SEND requests as critical.

>>/proc/sys/vm/in_emergency: write a non-zero value to tell the kernel that
>>the system is in an emergency state and authorize the kernel to dip into
>>the critical pool to satisfy critical allocations.
> Seems odd to me. Why make this another knob? How did you run to set this
> flag if you're in emergency and kswapd is going nuts?

We did this because we didn't want __GFP_CRITICAL allocations dipping into
the pool in the case of a transient low mem situation. In those cases we
want to force the task to do writeback to get a page (as usual), so that
the critical pool will be full when the system REALLY goes critical. We
also open the in_emergency file when the app starts so that we can just
write to it and don't need to try to open it when kswapd is going nuts.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at