Hi!The other reason we need a separate critical pool is to satifsy critical GFP_KERNEL allocations
I'll probably regret getting into this discussion, but:
Or Alan's suggested revivalDropping non-critical packets is still in our plan, but I don't think that
of the old code to drop non-critical network patches in duress.
is a FULL solution. As we mentioned before on that topic, you can't tell
if a packet is critical until AFTER you receive it, by which point it has
already had an skbuff (hopefully) allocated for it. If your network
traffic is coming in faster than you can receive, examine, and drop
non-critical packets you're hosed.
Why? You run out of atomic memory, start dropping the packets before
they even enter the kernel memory, and process backlog in the
meantime. Other hosts realize you are dropping packets and slow down,
or, if they are malicious, you just end up consistently dropping 70%
of packets. But that's okay.
I still think some sort of reserve pool
is necessary to give the networking stack a little breathing room when
under both memory pressure and network load.
"Lets throw some memory there and hope it does some good?" Eek? What
about auditing/fixing the networking stack, instead?
Yes, it is true that sizing the critical pool may be difficult if we use it for all incoming allocations.* this doesn't really solve the problem (network can still starve)Only if the pool is not large enough. One can argue that sizing the pool
appropriately is impossible (theoretical incoming traffic over a GigE card
or two for a minute or two is extremely large), but then I guess we
shouldn't even try to fix the problem...?
And what problem are you trying to fix, anyway? Last time I asked I
got reply around some strange clustering solution that absolutely has
to survive two minutes. And no, your patches do not even solve that,
because sizing the pool is impossible.