From: Hubertus Franke <frankeh@watson.ibm.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Lse-tech] Re: CPUSET Proposal
Date: Fri, 26 Sep 2003 13:29:57 +0000 [thread overview]
Message-ID: <marc-linux-ia64-106458305921458@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106444308519469@msgid-missing>
Sylvain Jeaugey wrote:
>>>With cpusets each application can ask the kernel for 5 cpus
>>>(or a wrapper that invokes the application can do so), and then
>>>the application can happily divide its work between virtual cpus
>>>0, 1, 2, 3, 4 (using sched_setaffinity()). The kernel can be smart
>>>and provide different physical cpus for each of the cpusets.
>>>
>>>
>Actually, the intelligence is located in the wrapper application. The
>kernel part of cpusets is given absolute masks. The virtualization is
>located in the fact that calls to sched_setaffinity() are interpreted
>within the cpuset, and that /proc/cpuinfo is also modified to reflect
>available CPUs.
>
>
>
Exactly .... virtualization of the virtual cpu number is the trick to
isolation from a code base
perspective .... it
>>In this case, the applications can get all of current affinity info by
>>calling sched_getaffinity(). Thus, the applications can schedule the
>>processes to different cpus without bothering kernel.
>>
>>
>The problem is not only to run on a different CPU. We want that the used
>CPU is decided by the admin and not the application. Otherwise you would
>have no control on it. It could have been a solution for applications we
>write like MPI (and that is the first thing we did).
>But we wanted to create something that could be a little united for all
>applications, without rewrite of applications. We add a lot of customized
>apps, each having been hacked to do something like this, but this resulted
>in a huge mess, lots of different configuration files, and no
>interoperability. By pushing it in the kernel, everything is _simple_ and
>_united_.
>
>Sylvain
>
>
>
>
Yipp, the lesson from the MPI ( I was involved in that as the
implementer of the first IBM MPI implementation
for the IBM SP2) is that these abstractions (such as communicators,
topologies) really mattered. It allowed application
writers to code algorithms without worrying how many cpu's which cpu,
who's the next physical neighbor.
It stayed at the virtual level.
cpusets are the same .
Enough on this topic now .. :-)
-- Hubertus Franke (CKRM team)
prev parent reply other threads:[~2003-09-26 13:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-24 22:26 [Lse-tech] Re: CPUSET Proposal Hanna Linder
2003-09-25 5:39 ` Paul Jackson
2003-09-25 5:48 ` William Lee Irwin III
2003-09-25 6:09 ` Paul Jackson
2003-09-25 6:23 ` William Lee Irwin III
2003-09-25 6:38 ` Paul Jackson
2003-09-25 6:44 ` William Lee Irwin III
2003-09-25 6:51 ` Paul Jackson
2003-09-25 6:59 ` William Lee Irwin III
2003-09-25 7:11 ` Paul Jackson
2003-09-25 13:11 ` Hubertus Franke
2003-09-25 13:19 ` Hubertus Franke
2003-09-25 13:21 ` Hubertus Franke
2003-09-25 13:26 ` Simon Derr
2003-09-25 16:50 ` Dave Hansen
2003-09-25 18:49 ` Luck, Tony
2003-09-25 20:28 ` Yu, Fenghua
2003-09-26 7:17 ` Sylvain Jeaugey
2003-09-26 7:47 ` Sylvain Jeaugey
2003-09-26 12:57 ` Hubertus Franke
2003-09-26 13:29 ` Hubertus Franke [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=marc-linux-ia64-106458305921458@msgid-missing \
--to=frankeh@watson.ibm.com \
--cc=linux-ia64@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