Thread (128 messages) 128 messages, 16 authors, 2006-08-25

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

From: David Miller <davem@davemloft.net>
Date: 2006-08-13 23:55:19
Also in: lkml, netdev

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help