public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dinakar Guniguntala <dino@in.ibm.com>
To: Paul Jackson <pj@sgi.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Paul Menage <menage@google.com>,
	Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
	Martin Bligh <mbligh@google.com>,
	Rohit Seth <rohitseth@google.com>,
	dipankar@in.ibm.com
Subject: Re: [RFC] Cpuset: explicit dynamic sched domain control flags
Date: Wed, 18 Oct 2006 23:19:25 +0530	[thread overview]
Message-ID: <20061018174925.GB7885@in.ibm.com> (raw)
In-Reply-To: <20061016230351.19049.29855.sendpatchset@jackhammer.engr.sgi.com>

On Mon, Oct 16, 2006 at 04:03:51PM -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> I should get agreement from the other folks who care about the
> interaction of cpusets and sched domains before submitting this
> to Andrew for staging in *-mm.
> 
> In particular, I remain unsure of myself around the sched domain
> code, and could use some feedback from someone with more of a
> clue on whether I broke something here.
> 
> =======
> 
> I have long regretted hanging the ability to use cpusets to
> define dynamic scheduler domains off the 'cpu_exclusive' flag
> of cpusets.

I seem to recollect having this very discussion before and
we had agreed that backing up a cpu_exclusive cpuset with a 
sched domain was an optimization rather than overloading the 
cpu_exclusive flag and I dont think it has changed since then.

> 
> It sort of made sense, in that one wants to avoid overlapping
> sched domains to some extent.  However it conflicts with other
> uses and meanings of the cpu_exclusive flag.  In particular,
> a job manager cannot have an inactive job in a cpuset that
> overlaps an active job, and mark the active job as defining a
> sched domain.

Sorry I dont understand this at all. Particularly marking 
an active job as a sched domain (I am yet to read all of the
mails in this thread, so please bear with me if you have
answered this elsewhere)

The only additional thing that happens once a cpuset has a 
sched domain associated with it would that the rebalance code
running on cpus not part of this cpuset would now not pull
tasks from the exclusive cpuset. How is that bad in any way ??


> 
> In the interests of maintaining compatibility with the
> existing interface, we should not remove this overloading of
> the cpu_exclusive flag.  But we can add a new flag to define
> sched domains, and a second flag to activate this first flag.

[snip]

IMO this change is counter intuitive and pointless

	-Dinakar


  parent reply	other threads:[~2006-10-18 17:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-16 23:03 [RFC] Cpuset: explicit dynamic sched domain control flags Paul Jackson
2006-10-17 18:43 ` Siddha, Suresh B
2006-10-17 19:18   ` Paul Jackson
2006-10-18  2:01     ` Siddha, Suresh B
2006-10-18  7:05       ` Paul Jackson
2006-10-18 17:50         ` Siddha, Suresh B
2006-10-19  6:30           ` Paul Jackson
2006-10-19  6:39         ` Nick Piggin
2006-10-19  7:03           ` Paul Jackson
2006-10-19  8:09             ` Nick Piggin
2006-10-19  8:15               ` Paul Jackson
2006-10-19  8:18                 ` Paul Jackson
2006-10-18 17:49 ` Dinakar Guniguntala [this message]
2006-10-19  6:00   ` Paul Jackson
2006-10-19  6:28   ` 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=20061018174925.GB7885@in.ibm.com \
    --to=dino@in.ibm.com \
    --cc=Simon.Derr@bull.net \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=menage@google.com \
    --cc=pj@sgi.com \
    --cc=rohitseth@google.com \
    --cc=suresh.b.siddha@intel.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