linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org>
To: "David S. Miller" <davem@davemloft.net>,
	dlstevens@us.ibm.com, shemminger@osdl.org, ak@suse.de,
	linux-kernel@vger.kernel.org, mpm@selenic.com,
	netdev@vger.kernel.org, netdev-owner@vger.kernel.org,
	sri@us.ibm.com
Subject: Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
Date: Fri, 16 Dec 2005 09:35:20 +0100	[thread overview]
Message-ID: <E1EnB3h-0005DP-CW@be1.lrz> (raw)
In-Reply-To: 5jXhZ-4kj-19@gated-at.bofh.it

David S. Miller <davem@davemloft.net> wrote:

> The idea to mark, for example, IPSEC key management daemon's sockets
> as critical is flawed, because the key management daemon could hit a
> swap page over the iSCSI device.  Don't even start with the idea to
> lock the IPSEC key management daemon into ram with mlock().

How are you going to swap in the key manager if you need the key manager
for doing this?


However, I'd prefer a system where you can't dirty mor than (e.g.) 80 % of
RAM unless you need this to maintain vital system activity and not more
than 95 % unless it will help to get more clean RAM. (Like the priority
inheritance suggestion from this thread.) I suppose this to least
significantly reduce thrashing and give a very good chance of recovering
from memory pressure. Off cause the implementation won't be easy,
especially if userspace applications need to inherit priority from
different code paths, but in theory, it can be done.

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

       reply	other threads:[~2005-12-16  8:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5jUjW-8nu-7@gated-at.bofh.it>
     [not found] ` <5jWYp-3K1-19@gated-at.bofh.it>
     [not found]   ` <5jXhZ-4kj-19@gated-at.bofh.it>
2005-12-16  8:35     ` Bodo Eggert [this message]
2005-12-14  9:12 [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism Sridhar Samudrala
2005-12-14  9:22 ` Andi Kleen
2005-12-14 17:55   ` Sridhar Samudrala
2005-12-14 18:41     ` Andi Kleen
2005-12-14 19:20       ` David Stevens
2005-12-15  3:39     ` Matt Mackall
2005-12-15  4:30       ` David S. Miller
2005-12-15  5:02         ` Matt Mackall
2005-12-15  5:23           ` David S. Miller
2005-12-15  5:48             ` Matt Mackall
2005-12-15  5:53             ` Nick Piggin
2005-12-15  5:56             ` Stephen Hemminger
2005-12-15  8:44               ` David Stevens
2005-12-15  8:58                 ` David S. Miller
2005-12-15  9:27                   ` David Stevens
2005-12-15  5:42         ` Andi Kleen
2005-12-15  6:06           ` Stephen Hemminger
2005-12-15  7:37         ` Sridhar Samudrala
2005-12-15  8:21           ` David S. Miller
2005-12-15  8:35             ` Arjan van de Ven
2005-12-16  2:09             ` Sridhar Samudrala
2005-12-16 17:48               ` Stephen Hemminger
2005-12-16 18:38                 ` Sridhar Samudrala
2005-12-21  9:11                   ` Pavel Machek
2005-12-21  9:39                     ` David Stevens
2005-12-14 20:16 ` Jesper Juhl
2005-12-14 20:25   ` Ben Greear
2005-12-14 20:49   ` James Courtier-Dutton
2005-12-14 21:55     ` Sridhar Samudrala
2005-12-14 22:09       ` James Courtier-Dutton
2005-12-14 22:39         ` Ben Greear
2005-12-14 23:42           ` Sridhar Samudrala
2005-12-15  1:54     ` Mitchell Blank Jr
2005-12-15 11:38       ` James Courtier-Dutton
2005-12-15 11:47         ` Arjan van de Ven
2005-12-15 13:00           ` jamal
2005-12-15 13:07             ` Arjan van de Ven
2005-12-15 13:32               ` jamal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1EnB3h-0005DP-CW@be1.lrz \
    --to=harvested.in.lkml@7eggert.dyndns.org \
    --cc=7eggert@gmx.de \
    --cc=ak@suse.de \
    --cc=davem@davemloft.net \
    --cc=dlstevens@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=sri@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).