From: Paul Jackson <pj@sgi.com>
To: Dinakar Guniguntala <dino@in.ibm.com>
Cc: kurosawa@valinux.co.jp, taka@valinux.co.jp,
magnus.damm@gmail.com, linux-kernel@vger.kernel.org,
ckrm-tech@lists.sourceforge.net
Subject: Ok to change cpuset flags for sched domains? (was [PATCH 1/3] CPUMETER ...)
Date: Sun, 2 Oct 2005 00:01:59 -0700 [thread overview]
Message-ID: <20051002000159.3f15bf7a.pj@sgi.com> (raw)
In-Reply-To: <20050927084905.7d77bdde.pj@sgi.com>
Dinikar,
How much grief will it cause you if I make the following incompatible
change to the special boolean files in each cpuset directory?
I think I goofed in encouraging you to overload "cpu_exclusive"
with defining dynamic scheduler domains. I should have asked for a
separate flag to be added for that, say "sched_domain", which would
require "cpu_exclusive=1" as a precondition. Other attributes that
require cpu_exclusive or mem_exclusive are showing up, and it makes
more sense for each of them to get their own boolean, and leave the
"*_exclusive" flags to specify just the exclusive (no overlap with
sibling) attribute.
I don't have much code built on top of this yet, so it won't matter
much to me. But I worry about the affect that such an incompatible
change would have on your user code.
Here is the proposed change, as I first described it in Takahiro-san's
thread on cpumeter:
=====================================================================
The above proposal makes it more obvious than ever that I am starting
to overload the meaning of cpu_exclusive and mem_exclusive perhaps a
bit too much.
One or the other of the two *_exclusive flags should be required
preconditions for some of these special properties (sched domains,
GFP_KERNEL memory allocation confinement, oom killer confinement, cpu
metering and memory metering), but perhaps actually enabling any of
these special properties should be an additional and distinct choice.
Therefore I propose some new cpuset flags:
* 'sched_domain' to mark sched domains (now done by the cpu_exclusive
flag),
* 'kernel_memory' to mark the constraints on GFP_KERNEL allocations,
* 'oom_killer' to mark the constraints on oom killing,
* your 'meter_cpu' flag to mark a set of metered cpus, and
* your 'meter_mem' flag to mark a set of metered mems.
Each of these new flags would require the appropriate cpu_exclusive or
mem_exclusive flag on the same cpuset to already be set, but just
setting the *_exclusive flags by themselves would not be enough to get
you the special behaviour. You would also have to set the appropriate
one of these new flags.
So, for example, the condition to define a sched domain would change,
from just being the lowest level cpuset marked cpu_exclusive (or the
left over CPUs not marked exclusive), to being both that -and- having
its "sched_domain" flag marked True (or being the left over CPUs,
again).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2005-10-02 7:02 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 ` Paul Jackson [this message]
2005-10-03 14:00 ` Ok to change cpuset flags for sched domains? (was [PATCH 1/3] CPUMETER ...) 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 ` [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS Matthew Helsley
2005-09-08 13:14 ` 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=20051002000159.3f15bf7a.pj@sgi.com \
--to=pj@sgi.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=taka@valinux.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.