Re: [RFC][PATCH 2/9] deadlock prevention core

[David Miller <davem@davemloft.net>]

From: Daniel Phillips <phillips@google.com>
Date: Sun, 13 Aug 2006 15:05:25 -0700

> By the way, another way to avoid impact on the normal case is an
> experimental option such as CONFIG_PREVENT_NETWORK_BLOCKIO_DEADLOCK.

That would just make the solution look more like a hack, and "bolted
on" rather than designed.

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.

And here's the kick, there are other unrelated highly positive
consequences to using Evgeniy's network tree allocator.

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.
-
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/