Pavel Machek wrote:
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?
The other reason we need a separate critical pool is to satifsy critical
GFP_KERNEL allocations
when we are in emergency. These are made in the send side and we cannot
block/sleep.
If sending routines can work with constant ammount of memory, why use
kmalloc at all? Anyway I thought we were talking receiving side
earlier in the thread.
Ouch and wait a moment. You claim that GFP_KERNEL allocations can't
block/sleep? Of course they can, that's why they are GFP_KERNEL and
not GFP_ATOMIC.
I didn't meant GFP_KERNEL allocations cannot block/sleep? When in
emergency, we
want even the GFP_KERNEL allocations that are made by critical sockets
not to block/sleep.
So my original critical sockets patches changes the gfp flag passed to
these allocation requests
to GFP_KERNEL|GFP_CRITICAL.
Thanks
Sridhar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
