From: Dinakar Guniguntala <dino@in.ibm.com>
To: Paul Jackson <pj@sgi.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: Re: Ok to change cpuset flags for sched domains? (was [PATCH 1/3] CPUMETER ...)
Date: Mon, 3 Oct 2005 19:30:32 +0530 [thread overview]
Message-ID: <20051003140032.GA6629@in.ibm.com> (raw)
In-Reply-To: <20051002000159.3f15bf7a.pj@sgi.com>
I have been wanting to follow the cpumeter discussion more closely,
but currently am tied up. I hope to have more time towards the end of
this week.
I had a few queries below, though
On Sun, Oct 02, 2005 at 12:01:59AM -0700, Paul Jackson wrote:
> 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.
One of the reasons for overloading the cpu_exclusive flag was to
ensure that the rebalance code does not try to pull tasks unnecessarily
With the scheme that you are proposing that is a possibility if
you turn on the cpu_exclusive and meter_cpu for example and not
turn on sched_domain. Is there a reason why we would want to have
exclusive cpusets not attached to sched domains at all?
I am not entirely convinced that we can compare sched_domains and
meter_cpus.
However I am still open if there is a convincing reason to have
exclusive cpusets that dont form sched domains.
-Dinakar
next prev parent reply other threads:[~2005-10-03 13:52 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 [this message]
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=20051003140032.GA6629@in.ibm.com \
--to=dino@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=kurosawa@valinux.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=pj@sgi.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.