public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: dino@in.ibm.com
Cc: Simon.Derr@bull.net, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Cpuset: remove useless sched domain line
Date: Sun, 22 Oct 2006 02:16:19 -0700	[thread overview]
Message-ID: <20061022021619.189cc02f.pj@sgi.com> (raw)
In-Reply-To: <20061018172422.GA7885@in.ibm.com>

> >  	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


Not that it matters, but I don't think you need to OR in the current cpuset
cpus to the parents cpus (pspan) here, because they are already in pspan.

Look at the surrounding code:

        pspan = par->cpus_allowed;
        list_for_each_entry(c, &par->children, sibling) {
                if (is_cpu_exclusive(c))
                        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;

'pspan' starts out with all the parents cpus, which must be a superset
of currents cpus (cur->cpus_allowed.)

Then we subtract (cpus_andnot) from pspan the cpus in the cpu_exclusive
siblings of current.  Since current is not cpu_exclusive, and since the
cpus of its cpu_exclusive sibling cpusets cannot overlap with currents
cpus, we could not have subtracted any current cpu from pspan.

So pspan is still a superset of currents cpus.

So OR'ing in currents cpus to pspan is a no-op.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

      parent reply	other threads:[~2006-10-22  9:16 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
2006-10-19  5:12   ` Paul Jackson
2006-10-22  9:16   ` Paul Jackson [this message]

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=20061022021619.189cc02f.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=dino@in.ibm.com \
    --cc=linux-kernel@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