On Wed, 14 Dec 2005, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Wed, 14 Dec 2005 19:39:37 -0800 > > > I think we need a global receive pool and per-socket send pools. > > Mind telling everyone how you plan to make use of the global receive > pool when the allocation happens in the device driver and we have no > idea which socket the packet is destined for? What should be done for > non-local packets being routed? The device drivers allocate packets > for the entire system, long before we know who the eventually received > packets are for. It is fully anonymous memory, and it's easy to > design cases where the whole pool can be eaten up by non-local > forwarded packets. > > I truly dislike these patches being discussed because they are a > complete hack, and admittedly don't even solve the problem fully. I > don't have any concrete better ideas but that doesn't mean this stuff > should go into the tree. > > I think GFP_ATOMIC memory pools are more powerful than they are given > credit for. There is nothing preventing the implementation of dynamic > GFP_ATOMIC watermarks, and having "critical" socket behavior "kick in" > in response to hitting those water marks.
Does this mean that you are OK with having a mechanism to mark the sockets as critical and dropping the non critical packets under emergency, but you do not like having a separate critical page pool. Instead, you seem to be suggesting in_emergency to be set dynamically when we are about to run out of ATOMIC memory. Is this right? Thanks Sridhar - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
