> > > 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/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu