Re: [PATCH] kswapd fix & logic improvement

[Pavel Machek <pavel@elf.ucw.cz>]

Hi!

> > > Not only that, but the network activity X induces puts additional stress
> > > on an already low-memory system by allocating lots of unswappable memory.
> > > When might we see Pavel's patches to the networking stack meant to get
> > > swapping over TCP working, but I think they'll really help stability on 
> > > systems with low-memory and busy networks, get integrated?
> > 
> > Sorry? My patches are usable only if you are trying to swap over
> > network. They will not help on low-memory systems, unless that systems
> > also lack hard-drives. It is usually much better to swap onto local
> > drive than over network.
> 
> If they're setup the way I think they are, you're mistaken. ;-)  I'm
> thinking of the pathelogical case where the system is thrown into a state
> where atomic memory consumption is occurring faster than the system can
> free up memory.  This could occur on a system with, say 100Mbps ethernet
> and a low-end IDE drive (~5-7MBps peak) if we're using TCP with large
> windows and have a *large* number of sockets open and receiving data. 
> Incoming packets could consume up to 10MB of GFP_ATOMIC memory per second
> - ouch!  With your patch, once we hit a danger zone, the system starts
> dropping network packets, right? 

No. I create new priority level ('GFP_NUCLEONIC') which is allowed to
consume few last-resort pages. This pages will be used for networking,
only, and they will be used only for that single socked used for swapping.

>  That way there will still be enough
> memory for allocating buffer heads and such to swap out as
> nescessary... 

I thought that current swapping is deadlock-free. Am I wrong? [I tried
hard to make network swap deadlock-free. I trusted swap-to-disk code
to be deadlock-free...]

								Pavel
-- 
I'm really pavel@atrey.karlin.mff.cuni.cz. 	   Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).