From: Paul Jackson <pj@sgi.com>
To: "Paul Menage" <menage@google.com>
Cc: mbligh@google.com, nickpiggin@yahoo.com.au, akpm@osdl.org,
Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
dino@in.ibm.com, rohitseth@google.com, holt@sgi.com,
dipankar@in.ibm.com, suresh.b.siddha@intel.com
Subject: Re: [RFC] cpuset: remove sched domain hooks from cpusets
Date: Sat, 21 Oct 2006 13:55:16 -0700 [thread overview]
Message-ID: <20061021135516.5deaa3e4.pj@sgi.com> (raw)
In-Reply-To: <6599ad830610211123i35d2e132y8ef1e0f612b94877@mail.gmail.com>
> I'm not very familiar
> with the sched domains code but I guess it doesn't handle overlapping
> cpu masks very well?
As best as I can tell, the two motivations for explicity setting
sched domain partitions are:
1) isolating cpus for real time uses very sensitive to any interference,
2) handling load balancing on huge CPU counts, where the worse than linear
algorithms start to hurt.
The load balancing algorithms apparently should be close to linear, but
in the presence of many disallowed cpus (0 bits in tasks cpus_allowed),
I guess they have to work harder.
I still have little confidence that I understand this. Maybe if I say
enough stupid things about the scheduler domains and load balancing,
someone will get annoyed and try to educate me ;). Best of luck to
them.
It doesn't sound to me like your situation is a real time, very low
latency or jigger, sensitive application.
How many CPUs are you juggling? My utterly naive expectation would be
that dozens of CPUs should not need explicit sched domain partitioning,
but that hundreds of them would benefit from reduced time spent in
kernel/sched.c code if the sched domains were able to be partitioned
down to a significantly smaller size.
The only problem I can see that overlapping cpus_allowed masks presents
to this is that it inhibits partitioning down to smaller sched domains.
Apparently these partitions are system-wide hard partitions, such that
no load balancing occurs across partitions, so we should avoid creating
a partition that cuts across some tasks cpus_allowed mask.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2006-10-21 20:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 9:23 [RFC] cpuset: remove sched domain hooks from cpusets Paul Jackson
2006-10-19 10:24 ` Nick Piggin
2006-10-19 19:03 ` Paul Jackson
2006-10-19 19:21 ` Nick Piggin
2006-10-19 19:50 ` Martin Bligh
2006-10-20 0:14 ` Paul Jackson
2006-10-20 16:03 ` Nick Piggin
2006-10-20 17:29 ` Siddha, Suresh B
2006-10-20 19:19 ` Paul Jackson
2006-10-20 19:00 ` Paul Jackson
2006-10-20 20:30 ` Dinakar Guniguntala
2006-10-20 21:41 ` Paul Jackson
2006-10-20 22:35 ` Dinakar Guniguntala
2006-10-20 23:14 ` Siddha, Suresh B
2006-10-21 5:37 ` Paul Jackson
2006-10-23 4:31 ` Siddha, Suresh B
2006-10-23 5:59 ` Paul Jackson
2006-10-21 23:05 ` Paul Jackson
2006-10-22 12:02 ` Paul Jackson
2006-10-23 3:09 ` Paul Jackson
2006-10-20 21:46 ` Paul Jackson
2006-10-21 18:23 ` Paul Menage
2006-10-21 20:55 ` Paul Jackson [this message]
2006-10-21 20:59 ` Paul Menage
2006-10-22 10:51 ` Paul Jackson
2006-10-23 5:26 ` Siddha, Suresh B
2006-10-23 5:54 ` Paul Jackson
2006-10-23 5:43 ` Siddha, Suresh B
2006-10-23 6:02 ` Nick Piggin
2006-10-23 6:16 ` Paul Jackson
2006-10-23 16:03 ` Christoph Lameter
2006-11-09 10:59 ` Paul Jackson
2006-10-23 16:01 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2006-10-30 21:26 [RFC] cpuset: Remove " Dinakar Guniguntala
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=20061021135516.5deaa3e4.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