Messages in this thread |  | | Date | Mon, 25 Sep 2000 16:04:12 +0200 | From | Andrea Arcangeli <> | Subject | Re: the new VM |
| |
On Mon, Sep 25, 2000 at 03:39:51PM +0200, Ingo Molnar wrote: > Andrea, if you really mean this then you should not be let near the VM > balancing code :-)
What I mean is that the VM balancing is in the lower layer that knows anything about the per-socket gigabit ethernet skbs limits, the limit should live at the higher layer. For most code just checking for NULL in GFP is fine (for example do_anonymous_page). It's the caller (not the VM balancing developer) that shouldn't be let near his code if it allows his code to fill all the physical ram with his stuff causing the machine to run OOM.
> > Most dynamic big caches and kernel data can be shrinked dynamically > > during memory pressure (pheraps except skbs and I agree that for skbs > > on gigabit ethernet the thing is a little different). > > a big 'except'. You dont need gigabit for that, to the contrary, if the
I talked with Alexey about this and it seems the best way is to have a per-socket reservation of clean cache in function of the receive window. So we don't need an huge atomic pool but we can have a special lru with an irq spinlock that is able to shrink cache from irq as well.
> about how many D.O.S. attacks there are possible without implicit or > explicit bean counting.
Again: the bean counting and all the limit happens at the higher layer. I shouldn't know anything about it when I play with the lower layer GFP memory balancing code.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |