From: Dinakar Guniguntala <dino@in.ibm.com>
To: Paul Jackson <pj@sgi.com>
Cc: Simon.Derr@bull.net, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Cpuset: remove useless sched domain line
Date: Wed, 18 Oct 2006 22:54:22 +0530 [thread overview]
Message-ID: <20061018172422.GA7885@in.ibm.com> (raw)
In-Reply-To: <20061014045517.22007.863.sendpatchset@v0>
On Fri, Oct 13, 2006 at 09:55:17PM -0700, Paul Jackson wrote:
> Dinakar,
>
> (1) Does this patch look right to you?
>
> (2) I don't understand this code:
>
> * When do we ever create sched domains for cpusets
> that -are- cpu_exclusive? All I see here are
> calls to partition_sched_domains() with various
> permutations of pspan and cspan that are the
> cpus from various non-exclusive cpusets.
>
> * Why do we return (setting up no sched domains
> at this time) if the current cpuset's cpus
> covers all the non exclusive cpus of our parent,
> but continue on to make a sched domain just for
> our parent if there are other non-exclusive cpus
> in our sibling cpusets?
>
> ====
>
> Remove a useless line from the sched domain setup code in cpusets.
>
> When I removed the 'is_removed()' flag test from the sched domain
> setup code in cpusets, as part of my July 23, 2006 patch:
>
> Cpuset: fix ABBA deadlock with cpu hotplug lock
>
> I failed to notice that this opened the door to a little bit of code
> simplification. A line of code that had to cover for the possibility
> that a cpuset marked cpu_exclusive was marked for removal could
> be eliminated. In the code section visible in this patch, it is
> now the case that cur->cpus_allowed is always a subset of pspan,
> so it is always a no-op to cpus_or() cur->cpus_allowed into pspan.
>
> Signed-off-by: Paul Jackson <pj@sgi.com>
>
> ---
>
> kernel/cpuset.c | 1 -
> 1 files changed, 1 deletion(-)
>
> --- 2.6.19-rc1-mm1.orig/kernel/cpuset.c 2006-10-13 21:31:16.000000000 -0700
> +++ 2.6.19-rc1-mm1/kernel/cpuset.c 2006-10-13 21:32:20.000000000 -0700
> @@ -783,7 +783,6 @@ static void update_cpu_domains(struct cp
> cpus_andnot(pspan, pspan, c->cpus_allowed);
> }
> if (!is_cpu_exclusive(cur)) {
> - cpus_or(pspan, pspan, cur->cpus_allowed);
> if (cpus_equal(pspan, cur->cpus_allowed))
> return;
> cspan = CPU_MASK_NONE;
I dont think this is a valid optimization. What we are checking here
is if a previously exclusive cpuset has been changed to a non-exclusive one
(echo 0 > cpu_exclusive), we then OR all the cpus in the current cpuset
to the parent cpuset. We then rebuild a sched domain to include all of the cpus
in the current cpuset and those in the parent not part of exclusive children
So I dont see why this can be done away with
-Dinakar
next prev parent reply other threads:[~2006-10-18 17:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-14 4:55 [RFC] Cpuset: remove useless sched domain line Paul Jackson
2006-10-18 17:24 ` Dinakar Guniguntala [this message]
2006-10-19 5:12 ` Paul Jackson
2006-10-22 9:16 ` Paul Jackson
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=20061018172422.GA7885@in.ibm.com \
--to=dino@in.ibm.com \
--cc=Simon.Derr@bull.net \
--cc=linux-kernel@vger.kernel.org \
--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