Messages in this thread | | | Date | Sun, 13 Aug 2006 18:31:14 -0700 | From | Daniel Phillips <> | Subject | Re: [RFC][PATCH 2/9] deadlock prevention core |
| |
David Miller wrote: > I think there is more profitability from a solution that really does > something about "network memory", and doesn't try to say "these > devices are special" or "these sockets are special". Special cases > generally suck. > > We already limit and control TCP socket memory globally in the system. > If we do this for all socket and anonymous network buffer allocations, > which is sort of implicity in Evgeniy's network tree allocator design, > we can solve this problem in a more reasonable way.
This does sound promising, but...
It is not possible to solve this problem entirely in the network layer. At minimum, throttling is needed in the nbd driver, or even better, in the submit_bio path as we have it now. We also need a way of letting the virtual block device declare its resource needs, which we also have in some form. We also need a mechanism to guarantee level 2 delivery so we can drop unrelated packets if necessary, which exists in the current patch set.
So Evgeniy's work might well be a part of the solution, but it is not the whole solution.
> And here's the kick, there are other unrelated highly positive > consequences to using Evgeniy's network tree allocator.
Also good. But is it ready to use today? We need to actually fix the out of memory deadlock/performance bug right now so that remote storage works properly.
> It doesn't just solve the _one_ problem it was built for, it solves > several problems. And that is the hallmark signature of good design.
Great. But to solve the whole problem, the block IO system and the network layer absolutely must cooperate.
Regards,
Daniel
- 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/
| |