Messages in this thread | | | Date | Thu, 2 Dec 2004 16:18:39 -0800 | From | Andrew Morton <> | Subject | Re: Kernel 2.6.9 Multiple Page Allocation Failures |
| |
Lukas Hejtmanek <xhejtman@hell.sks3.muni.cz> wrote: > > On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > > It's quite possible that XFS is performing rather too many GFP_ATOMIC > > allocations and is depleting the page reserves. Although increasing > > /proc/sys/vm/min_free_kbytes should help there. > > Btw, how the min_free_kbytes works?
The page reclaim code and the page allocator will aim to keep that amount of memory free for emergency, IRQ and atomic allocations.
> I have up to 1MB TCP windows. If I'm running out of memory then kswapd should > try to free some memory (or bdflush).
yes, there's some latency involved. Especially on uniprocessor - if the CPU is stuck in an interrupt handler refilling a huge network Rx ring then waking kswapd won't do anything and you will run out of memory.
> But on GE I can receive data faster then > disk is able to swap or flush buffers. So I should keep min_free big enough to > give time to disk to flush/swap data?
All I can say is "experiment with it".
It might be useful to renice kswapd so that userspace processes do not increase its latency.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |