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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
