Re: [PATCH] kswapd fix & logic improvement

Pavel Machek (
Fri, 6 Mar 1998 15:40:19 +0100


> > > 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...]


I'm really 	   Pavel
Look at ;-).

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to