public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: dino@in.ibm.com, nickpiggin@yahoo.com.au, akpm@osdl.org,
	mbligh@google.com, menage@google.com, Simon.Derr@bull.net,
	linux-kernel@vger.kernel.org, rohitseth@google.com, holt@sgi.com,
	dipankar@in.ibm.com, suresh.b.siddha@intel.com
Subject: Re: [RFC] cpuset: add interface to isolated cpus
Date: Tue, 24 Oct 2006 08:44:55 -0700	[thread overview]
Message-ID: <20061024084455.477903a5.pj@sgi.com> (raw)
In-Reply-To: <20061023134730.62e791a2.pj@sgi.com>

pj wrote to Dinakar:
> The only twist to your patch I would like you to consider - instead
> of a 'sched_domain' flag marking where the partitions go, how about
> a flag that tells the kernel it is ok not to load balance tasks in
> a cpuset?

Dinakar - one possibility that might work well:

  Proceed with the 'sched_domain' patch you are working on, as you planned.

  (If you like, stop reading here ... <grin>.)

  Then I can propose a patch on top of that, to flip the kernel-user API
  to the "ok not to load balance" style I'm proposing.  This patch would:
    - leave your internal logic in place, as is,
    - remove your 'sched_domain' flag from the visible API (keep it internally),
    - add a 'cpu_must_load_balance' (default 1) flag to the API, and
    - add a bit of logic to set, top down, your internal sched_domain flag,
      based on the cpu_must_load_balance and parent sched_domain settings.

  Then we can all see these two alternative API styles, your sched_domain
  style and my cpu_must_load_balance style, and pick one (just by keeping
  or tossing my extra patch.)

A couple of aspects of my cpu_must_load_balance style that I like:

  * The batch scheduler can turn off requiring load balancing on its
    inactive cpusets, without worrying about whether it has the right
    (exclusive control) to do that or not.

  * I figure that users will relate better to a choice of whether or not
    they require cpu load balancing, than they will to the question of
    where to partition scheduler domains.

Of course, if Nick succeeds on his mission to convince us that we can
do this automatically, then the above doesn't matter, and we'd need a
different patch altogether.

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

  reply	other threads:[~2006-10-24 15:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-19  9:26 [RFC] cpuset: add interface to isolated cpus Paul Jackson
2006-10-19 10:17 ` Nick Piggin
2006-10-19 17:55   ` Paul Jackson
2006-10-19 18:07     ` Nick Piggin
2006-10-19 18:56       ` Paul Jackson
2006-10-19 19:03         ` Nick Piggin
2006-10-20  3:37           ` Paul Jackson
2006-10-20  8:02             ` Nick Piggin
2006-10-20 14:52               ` Nick Piggin
2006-10-20 20:03                 ` Paul Jackson
2006-10-20 19:59               ` Paul Jackson
2006-10-20 20:01               ` Paul Jackson
2006-10-20 20:59                 ` Siddha, Suresh B
2006-10-21  1:33                   ` Paul Jackson
2006-10-21  6:14                 ` Nick Piggin
2006-10-21  7:24                   ` Paul Jackson
2006-10-21 10:51                     ` Nick Piggin
2006-10-22  4:54                       ` Paul Jackson
2006-10-20 21:04 ` Dinakar Guniguntala
2006-10-23  3:18   ` Paul Jackson
2006-10-23  5:07     ` Nick Piggin
2006-10-23  5:51       ` Paul Jackson
2006-10-23  5:40         ` Siddha, Suresh B
2006-10-23  6:06           ` Paul Jackson
2006-10-23  6:07           ` Paul Jackson
2006-10-23  6:17         ` Nick Piggin
2006-10-23  6:41           ` Paul Jackson
2006-10-23  6:49             ` Nick Piggin
2006-10-23  6:48           ` Paul Jackson
2006-10-23 20:58           ` Paul Jackson
2006-10-23 19:50       ` Dinakar Guniguntala
2006-10-23 20:47         ` Paul Jackson
2006-10-24 15:44           ` Paul Jackson [this message]
2006-10-25 19:40         ` 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=20061024084455.477903a5.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=dino@in.ibm.com \
    --cc=dipankar@in.ibm.com \
    --cc=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=menage@google.com \
    --cc=nickpiggin@yahoo.com.au \
    --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