From: Henry Bausley <hbausley@domain.hid>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] multicore: reserving core(s) for Xenomai
Date: Wed, 14 Sep 2011 07:39:34 -0700 [thread overview]
Message-ID: <1316011174.8027.7.camel@domain.hid> (raw)
In-Reply-To: <4E70AADF.6010201@domain.hid>
Jan does the lack of 100% isolation imply if a Xenomai kernel thread
running on the isolated CPU used to much duty cycle Linux would lock up
since it couldn't get a chance at the isolated cpu.
On Wed, 2011-09-14 at 15:23 +0200, Jan Kiszka wrote:
> On 2011-09-14 15:13, Gilles Chanteperdrix wrote:
> > On 09/14/2011 02:18 PM, Henri Roosen wrote:
> >> We'll start experiments running our Xenomai application on a
> >> multi-core CPU (x86/ARM). I'm sure there are some Xenomai users who
> >> already have experience with it.
> >>
> >> What I would like to do is to run the Xenomai realtime threads on one
> >> core of the multi-core CPU. And I would like to reserve this core only
> >> for the Xenomai realtime threads.
> >>
> >> I'm using the Native API, so I can pass the CPU affinity flags for the
> >> Xenomai threads during task creation/shadow. But how can I make sure
> >> other threads will not make use of the same processor? I cannot call
> >> taskset for every task that is spawned... right?
> >>
> >> Are there any idea's on how this configuration could be made easier?
> >> It would be nice if there was a kernel config option to reserve
> >> core(s) for Xenomai that Linux will not use.
> >>
> >> Any ideas and help are welcome!
> >
> > The kernel has an "isolcpus" option, which allows to specify which cpus
> > should not be used by Linux.
>
> ...or cgroups. isolcpus is much simpler to set up, but less strict (any
> process tuning its affinity is able to circumvent this, but not cgroup
> isolations).
>
> >
> > See Documentation/kernel-parameters.txt in the linux kernel sources for
> > an explanation.
>
> ...but be warned that there is no 100% isolation. Quite a few Linux
> kernel threads and IPIs are required to continue hitting any online CPU.
> Things are improving to reduce those noise Linux-wise, but there is no
> 100% in sight yet.
>
> Jan
>
Outbound scan for Spam or Virus by Barracuda at Delta Tau
next prev parent reply other threads:[~2011-09-14 14:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-14 12:18 [Xenomai-help] multicore: reserving core(s) for Xenomai Henri Roosen
2011-09-14 13:13 ` Kim Mathiassen
2011-09-14 13:13 ` Gilles Chanteperdrix
2011-09-14 13:23 ` Jan Kiszka
2011-09-14 14:39 ` Henry Bausley [this message]
2011-09-14 17:53 ` Jan Kiszka
2011-09-14 13:24 ` Eric Noulard
2011-09-14 13:42 ` Henri Roosen
2011-09-14 15:00 ` Jeff Weber
2011-09-14 17:49 ` Gilles Chanteperdrix
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=1316011174.8027.7.camel@domain.hid \
--to=hbausley@domain.hid \
--cc=jan.kiszka@domain.hid \
--cc=xenomai@xenomai.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.