Messages in this thread | | | Date | Wed, 14 Dec 2005 23:37:37 -0800 (PST) | From | Sridhar Samudrala <> | Subject | Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism |
| |
On Wed, 14 Dec 2005, David S. Miller wrote:
> From: Matt Mackall <mpm@selenic.com> > 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |