All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [RFC] shadow threads with prio 0 / SCHED_NORMAL
Date: Fri, 21 Apr 2006 17:47:18 +0200	[thread overview]
Message-ID: <4448FE86.4050503@domain.hid> (raw)
In-Reply-To: <17480.63623.600656.828303@domain.hid>

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Jan Kiszka wrote:
>  > > Hi,
>  > > 
>  > > this is an experimental hack to open the non-rt priority levels of Linux
>  > > to Xenomai shadow threads, i.e. allow shadows to be scheduled under
>  > > SCHED_NORMAL when in secondary mode. The scenario are typical borderline
>  > > threads between RT and non-RT: they share a critical code path with RT
>  > > threads, maybe mutex protected, but they are mostly time-sharing threads
>  > > which do not need SCHED_FIFO for this.
>  > > 
>  > > The patch (be careful, quick-hack!) addresses the prio level 0 in the
>  > > ipipe patch, the nucleus/shadow subsystem, and the native skin. A quick
>  > > test with the attached demo showed the expected behaviour so far: no
>  > > lock-up during busy-waiting in secondary mode, prio-boost when holding
>  > > the lock (visible via /proc/xenomai/sched), no obvious side effects.
>  > > 
>  > > Any comments? Does this break other things in a subtle way?
>  > 
>  > An initial comment on the general usage of this extension: since the 
>  > threads running in SCHED_OTHER/SCHED_NORMAL mode are expected to run 
>  > non-RT workloads while still being able to use the RT infrastructure for 
>  >   communicating with the rest of the RT system, I think that the best 
>  > places for creating such hybrids are in the rt_task_shadow (native skin) 
>  > and pthread_setschedparam (POSIX skin) calls, which would make it clear 
>  > that a regular Linux thread is involved [and as such needs to be created 
>  > by a normal call to pthread_create()], which also happens to benefit 
>  > from the RT infrastructure mainly for communication/sychronization purpose.
> 
> What about keeping SCHED_RR as the default scheduling policy and
> requiring users to manually select SCHED_NORMAL in thread creation
> attributes in order to create hybrid threads with pthread_create ?
> 

No objection a priori, but what would this buy us?

-- 

Philippe.


  reply	other threads:[~2006-04-21 15:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19 22:01 [Xenomai-core] [RFC] shadow threads with prio 0 / SCHED_NORMAL Jan Kiszka
2006-04-20 12:55 ` Philippe Gerum
2006-04-21 10:46 ` Philippe Gerum
2006-04-21 15:21   ` Gilles Chanteperdrix
2006-04-21 15:47     ` Philippe Gerum [this message]
2006-04-21 16:00       ` Gilles Chanteperdrix
2006-04-21 16:41         ` Philippe Gerum
2006-04-21 17:40           ` Gilles Chanteperdrix
2006-04-21 17:50             ` Philippe Gerum
2006-04-21 18:18               ` Jan Kiszka
2006-04-21 21:40                 ` Philippe Gerum
2006-04-21 16:03     ` Jan Kiszka
2006-06-04 17:58 ` Philippe Gerum

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=4448FE86.4050503@domain.hid \
    --to=rpm@xenomai.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --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.