public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Lse-tech] Re: CPUSET Proposal
Date: Thu, 25 Sep 2003 06:23:51 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106447099207495@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106444308519469@msgid-missing>

At some point in the past, I wrote:
>> This sounds like it has progressively more commonality with CKRM; the
>> notion is of a workclass, not of a purely cpu-oriented notion.

On Wed, Sep 24, 2003 at 11:09:58PM -0700, Paul Jackson wrote:
> I _knew_ I shouldn't have thrown in that paragraph that began "There are
> also some resource management capabilities, ...".
> There are two aspects to CKRM - a common classification of service levels,
> and hooks in each scheduler of resources to respect those levels.
> These cpusets, either as proposed, or possible fancier forms that also
> manage memory, do not replace, cannot be replaced by, and do not compete
> with CKRM.  Rather they cooperate with CKRM, and represent one more
> place, along side network drivers, schedulers and memory allocators,
> that eventually will want to respect CKRM service levels.
> The point of _this_ subthread was to consider whether this could more or
> less entirely be done in user space.  The two aspects even of Simon's
> current proposal that I don't see can be done in user space are the
> migration, and the permission model.

Well, the thing is, CKRM essentially has the cross-resource bits and
makes up some group that can be joined and departed from and inherited
and so on with all the right knobs. So the question is "what does CKRM
lack that cpusets needs?" It sounds to me like the major point missing
is "nobody else can touch this cpu" if I read cpusets properly.


-- wli

  parent reply	other threads:[~2003-09-25  6:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24 22:26 [Lse-tech] Re: CPUSET Proposal Hanna Linder
2003-09-25  5:39 ` Paul Jackson
2003-09-25  5:48 ` William Lee Irwin III
2003-09-25  6:09 ` Paul Jackson
2003-09-25  6:23 ` William Lee Irwin III [this message]
2003-09-25  6:38 ` Paul Jackson
2003-09-25  6:44 ` William Lee Irwin III
2003-09-25  6:51 ` Paul Jackson
2003-09-25  6:59 ` William Lee Irwin III
2003-09-25  7:11 ` Paul Jackson
2003-09-25 13:11 ` Hubertus Franke
2003-09-25 13:19 ` Hubertus Franke
2003-09-25 13:21 ` Hubertus Franke
2003-09-25 13:26 ` Simon Derr
2003-09-25 16:50 ` Dave Hansen
2003-09-25 18:49 ` Luck, Tony
2003-09-25 20:28 ` Yu, Fenghua
2003-09-26  7:17 ` Sylvain Jeaugey
2003-09-26  7:47 ` Sylvain Jeaugey
2003-09-26 12:57 ` Hubertus Franke
2003-09-26 13:29 ` Hubertus Franke

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=marc-linux-ia64-106447099207495@msgid-missing \
    --to=wli@holomorphy.com \
    --cc=linux-ia64@vger.kernel.org \
    /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