From: Robert Love <rml@tech9.net>
To: Jason Baietto <jason.baietto@ccur.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Multiprocessor Control Interfaces
Date: 11 Dec 2001 01:29:07 -0500 [thread overview]
Message-ID: <1008052151.4300.18.camel@phantasy> (raw)
In-Reply-To: <1008015291.15138.0.camel@soybean>
In-Reply-To: <1008015291.15138.0.camel@soybean>
On Mon, 2001-12-10 at 15:14, Jason Baietto wrote:
> I'm currently working on adding multiprocessor control interfaces
> to Linux. My current efforts can be found here:
>
> http://www.ccur.com/realtime/oss
>
> These are clean-room implementations of similar tools that have
> been available in our proprietary *nix for quite some time, and
> so the interfaces have a fair amount of mileage under their belts.
> Note that the scope is somewhat wider than just MP.
Ahh, very neat. This is a useful tool.
One idea would be to allow users to set CPUs processes _can't_ run on.
On high-end systems sometimes a CPU is affined to a particular IRQ (say,
network interface). Another situation is where you bind a RT task to a
given CPU. In these situations, you want everything else to _not_ run
on the CPUs. I.e., `run --bind=!1' (note its easy to generate the
bitmask here too, by ANDing the inverse of the given CPU against -1).
At any rate, what is needed most is to standardize on an interface for
these scheduling mechanisms. I guess its just CPU affinity we have to
go ... since not much progress was made of my (proc-based) method vs.
Ingo's (syscall-based) method, at this point either of the two being
merged would make me happy.
> These services rely upon Robert Love's CPU Affinity patch
> (version 2.4.16-1 was used for testing) which is available here:
>
> http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/v2.4/
I assume you have no problems with it ... I think I'd like to add the
change that the CPUs reported correspond to the physical CPU number and
not the logical value we derive. On x86 this won't make a difference,
but its a proper method I suspect.
Robert Love
next prev parent reply other threads:[~2001-12-11 6:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-10 20:14 [RFC] Multiprocessor Control Interfaces Jason Baietto
2001-12-11 6:29 ` Robert Love [this message]
2001-12-11 16:18 ` Jason Baietto
-- strict thread matches above, loose matches on Subject: below --
2001-12-11 1:59 Jason Baietto
2001-12-11 1:38 ` Tim Hockin
2001-12-11 16:31 ` Jason Baietto
2001-12-11 18:16 ` Tim Hockin
2001-12-12 15:11 ` Jason Baietto
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=1008052151.4300.18.camel@phantasy \
--to=rml@tech9.net \
--cc=jason.baietto@ccur.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.