Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

On Mon, 2007-09-10 at 12:29 -0700, Christoph Lameter wrote:
> On Wed, 5 Sep 2007, Nick Piggin wrote:
> 
> > Implementation issues aside, the problem is there and I would like to
> > see it fixed regardless if some/most/or all users in practice don't
> > hit it.
> 
> I am all for fixing the problem but the solution can be much simpler and 
> more universal. F.e. the amount of tcp data in flight may be controlled 
> via some limit so that other subsystems can continue to function even if 
> we are overwhelmed by network traffic.

With swap over network you need not only protect other subsystems from
networking, but you also have to guarantee networking will in some form
stay functional, otherwise you'll never receive the writeout completion.

>  Peter's approach establishes the 
> limit by failing PF_MEMALLOC allocations. 

I'm not failing PF_MEMALLOC allocations. I'm more stringent in failing !
PF_MEMALLOC allocations.

> If that occurs then other 
> subsystems (like the disk, or even fork/exec or memory management 
> allocation) will no longer operate since their allocations no longer 
> succeed which will make the system even more fragile and may lead to 
> subsequent failures.

Failing allocations should never be a stability problem, we have the
fault-injection framework which allows allocations to fail randomly -
this should never crash the kernel - if it does its a BUG.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]