Sridhar Samudrala wrote:
On Wed, 2005-12-14 at 20:49 +0000, James Courtier-Dutton wrote:
Jesper Juhl wrote:
On 12/14/05, Sridhar Samudrala <[EMAIL PROTECTED]> wrote:
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority communications over a critical socket
to succeed even under very low memory conditions that last for a couple of
minutes. It uses the critical page pool facility provided by Matt's patches
that he posted recently on lkml.
http://lkml.org/lkml/2005/12/14/34/index.html
This mechanism provides a new socket option SO_CRITICAL that can be used to
mark a socket as critical. A critical connection used for emergency
So now everyone writing commercial apps for Linux are going to set
SO_CRITICAL on sockets in their apps so their apps can "survive better
under pressure than the competitors aps" and clueless programmers all
over are going to think "cool, with this I can make my app more
important than everyone elses, I'm going to use this". When everyone
and his dog starts to set this, what's the point?
I don't think the initial patches that Matt did were intended for what
you are describing.
When I had the conversation with Matt at KS, the problem we were trying
to solve was "Memory pressure with network attached swap space".
I came up with the idea that I think Matt has implemented.
Letting the OS choose which are "critical" TCP/IP sessions is fine. But
letting an application choose is a recipe for disaster.
We could easily add capable(CAP_NET_ADMIN) check to allow this option to
be set only by privileged users.
Thanks
Sridhar
Sridhar,
Have you actually thought about what would happen in a real world senario?
There is no real world requirement for this sort of user land feature.
In memory pressure mode, you don't care about user applications. In
fact, under memory pressure no user applications are getting scheduled.
All you care about is swapping out memory to achieve a net gain in free
memory, so that the applications can then run ok again.
James
-
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
