From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 May 2007 11:02:51 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH 0/5] make slab gfp fair In-Reply-To: <20070517175327.GX11115@waste.org> Message-ID: References: <20070514131904.440041502@chello.nl> <1179385718.27354.17.camel@twins> <20070517175327.GX11115@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Matt Mackall Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Graf , David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg List-ID: On Thu, 17 May 2007, Matt Mackall wrote: > Simply stated, the problem is sometimes it's impossible to free memory > without allocating more memory. Thus we must keep enough protected > reserve that we can guarantee progress. This is what mempools are for > in the regular I/O stack. Unfortunately, mempools are a bad match for > network I/O. > > It's absolutely correct that performance doesn't matter in the case > this patch is addressing. All that matters is digging ourselves out of > OOM. The box either survives the crisis or it doesn't. Well we fail allocations in order to do so and these allocations may be even nonatomic allocs. Pretty dangerous approach. > It's also correct that we should hardly ever get into a situation > where we trigger this problem. But such cases are still fairly easy to > trigger in some workloads. Swap over network is an excellent example, > because we typically don't start swapping heavily until we're quite > low on freeable memory. Is it not possible to avoid failing allocs? Instead put processes to sleep? Run synchrononous reclaim? -- 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: email@kvack.org