From: Matthew Helsley <matthltc@us.ibm.com>
To: magnus.damm@gmail.com
Cc: KUROSAWA Takahiro <kurosawa@valinux.co.jp>,
Paul Jackson <pj@sgi.com>,
dino@in.ibm.com, LKML <linux-kernel@vger.kernel.org>,
CKRM-Tech <ckrm-tech@lists.sourceforge.net>
Subject: Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS
Date: Fri, 09 Sep 2005 15:26:23 -0700 [thread overview]
Message-ID: <1126304783.12346.1587.camel@stark> (raw)
In-Reply-To: <aec7e5c305090821126cea6b57@mail.gmail.com>
On Fri, 2005-09-09 at 13:12 +0900, Magnus Damm wrote:
> On 9/9/05, KUROSAWA Takahiro <kurosawa@valinux.co.jp> wrote:
> > On Thu, 8 Sep 2005 05:02:32 -0700
> > Paul Jackson <pj@sgi.com> wrote:
> > > One of my passions is to avoid special cases across API boundaries.
> > >
> > > I am proposing that you don't do subcpusets like this.
> > >
> > > Consider the following alternative I will call 'cpuset meters'.
> > >
> > > For each resource named 'R' (cpu and mem, for instance):
> > > * Add a boolean flag 'meter_R' to each cpuset. If set, that R is
> > > metered, for the tasks in that cpuset or any descendent cpuset.
> > > * If a cpuset is metered, then files named meter_R_guar, meter_R_lim
> > > and meter_R_cur appear in that cpuset to manage R's usage by tasks
> > > in that cpuset and descendents.
> > > * There are no additional rules that restrict the ability to change
> > > various other cpuset properties such as cpus, mems, cpu_exclusive,
> > > mem_exclusive, or notify_on_release, when a cpuset is metered.
> > > * It might be that some (or by design all) resource controllers do
> > > not allow nesting metered cpusets. I don't know. But one should
> > > (if one has permission) be able to make child cpusets of a metered
> > > cpuset, just like one can of any other cpuset.
> > > * A metered cpuset might well have cpus or mems that are not the
> > > same as its parent, just like an unmetered cpuset ordinarly does.
> >
> > Jackson-san's idea looks good for me because users don't need
> > to create special cpusets (parents of subcpusets or subcpusets).
> > From the point of users, maybe they wouldn't like to create
> > special cpusets.
>
> Yes, from the user POV it must be good to keep the hierarchical model.
> Ckrm and cpusets both provide a tree with descendents, children and
> parents. This hierarchical model is very nice IMO and provides a
> powerful API for the user.
>
> > As for the resource controller that I've posted, it assumes
> > that there are groups of tasks that share the same cpumasks/nodemasks,
> > and that there are no hierarchy in that groups in order to make
> > things easier. I'll investigate how I can attach the resource
> > controller to the cpuset meters.
>
> Subcpusets, compared to cpusets and ckrm, gives the user a flat model.
> No hierarchy. Limited functionality compared to the hierachical model.
>
> But what I think is important to keep in mind here is that cpusets and
> subcpusets do very different things. If I understand cpusets
> correctly, each cpuset may share processors or memory nodes with other
> cpusets. One task running on a shared processor may starve other
> cpusets using the same processor. This design works well with cpusets,
> but for resource controllers that must provide some kind of guarantee,
> this starvation is unsuitable.
>
> And we already have an hierarchical alternative: ckrm. But look at the
> complexity and the amount of code. I believe that the complexity in
> ckrm mainly comes from the hierarchical model.
I've been trying to find ways to significantly reduce CKRM's kernel
footprint. I recently posted an RFC patch to CKRM-Tech describing a
5000-line reduction:
http://sourceforge.net/mailarchive/forum.php?thread_id=8132624&forum_id=35191
Feedback on the approach presented in the RFC patch would be
appreciated.
> Maybe it is possible to have an hierarchical model and keep the
> framework simple and easy to understand while providing guarantees,
> I'm not sure. But until that happens, I'm quite happy with a simple,
> limited flat model.
>
> / magnus
next prev parent reply other threads:[~2005-09-09 22:32 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-08 5:39 [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS KUROSAWA Takahiro
2005-09-08 7:23 ` Paul Jackson
2005-09-08 8:18 ` KUROSAWA Takahiro
2005-09-08 12:02 ` Paul Jackson
2005-09-09 1:38 ` KUROSAWA Takahiro
2005-09-09 4:12 ` Magnus Damm
2005-09-09 5:55 ` Paul Jackson
2005-09-09 7:52 ` Magnus Damm
2005-09-09 8:39 ` Paul Jackson
2005-09-09 11:38 ` Hirokazu Takahashi
2005-09-09 13:31 ` Paul Jackson
2005-09-10 7:11 ` Hirokazu Takahashi
2005-09-10 8:52 ` Paul Jackson
2005-09-11 16:02 ` Hirokazu Takahashi
2005-09-26 9:33 ` [PATCH 0/3] CPUMETER (Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS) KUROSAWA Takahiro
2005-10-02 4:20 ` Paul Jackson
2005-10-04 2:49 ` KUROSAWA Takahiro
2005-09-26 9:34 ` [PATCH 1/3] CPUMETER: add cpumeter framework to the CPUSETS KUROSAWA Takahiro
2005-09-27 8:37 ` Paul Jackson
2005-09-27 9:22 ` Nick Piggin
2005-09-27 15:53 ` [ckrm-tech] " Paul Jackson
2005-09-27 21:45 ` Chandra Seetharaman
2005-09-28 6:35 ` KUROSAWA Takahiro
2005-09-28 10:08 ` Hirokazu Takahashi
2005-09-28 10:32 ` KUROSAWA Takahiro
2005-09-27 11:39 ` KUROSAWA Takahiro
2005-09-27 15:49 ` [ckrm-tech] " Paul Jackson
2005-09-28 6:21 ` KUROSAWA Takahiro
2005-09-28 6:43 ` Paul Jackson
2005-09-28 7:08 ` Paul Jackson
2005-09-28 7:53 ` KUROSAWA Takahiro
2005-09-28 16:49 ` Paul Jackson
2005-09-29 2:53 ` KUROSAWA Takahiro
2005-09-29 2:58 ` Paul Jackson
2005-09-30 9:39 ` Simon Derr
2005-09-30 14:21 ` Paul Jackson
2005-10-02 7:01 ` Ok to change cpuset flags for sched domains? (was [PATCH 1/3] CPUMETER ...) Paul Jackson
2005-10-03 14:00 ` Dinakar Guniguntala
2005-10-03 23:36 ` [ckrm-tech] " Paul Jackson
2005-09-28 9:25 ` [PATCH][BUG] fix memory leak on reading cpuset files after seeking beyond eof KUROSAWA Takahiro
2005-09-28 13:42 ` Paul Jackson
2005-09-28 13:42 ` [PATCH] cpuset read past eof memory leak fix Paul Jackson
2005-09-28 15:01 ` Linus Torvalds
2005-09-28 17:53 ` Paul Jackson
2005-09-28 18:03 ` Linus Torvalds
2005-09-28 18:03 ` Randy.Dunlap
2005-09-28 19:04 ` [ckrm-tech] " Paul Jackson
2005-09-28 14:29 ` [PATCH 1/3] CPUMETER: add cpumeter framework to the CPUSETS Paul Jackson
2005-09-26 9:34 ` [PATCH 2/3] CPUMETER: CPU resource controller KUROSAWA Takahiro
2005-09-26 9:34 ` [PATCH 3/3] CPUMETER: connect the CPU resource controller to CPUMETER KUROSAWA Takahiro
2005-09-09 22:26 ` Matthew Helsley [this message]
2005-09-08 13:14 ` [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS Dinakar Guniguntala
2005-09-08 14:11 ` Dipankar Sarma
2005-09-08 14:55 ` Paul Jackson
2005-09-08 14:59 ` Paul Jackson
2005-09-08 22:51 ` [ckrm-tech] " Chandra Seetharaman
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=1126304783.12346.1587.camel@stark \
--to=matthltc@us.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dino@in.ibm.com \
--cc=kurosawa@valinux.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=pj@sgi.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).