All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@siemens.com>, xenomai@xenomai.org
Subject: Re: [Xenomai] Philippe Gerum : lib/cobalt: add config switch to enable lazy setsched update mode
Date: Mon, 25 Apr 2016 18:05:43 +0200	[thread overview]
Message-ID: <571E4057.7000703@xenomai.org> (raw)
In-Reply-To: <571E312A.9040903@siemens.com>

On 04/25/2016 05:00 PM, Jan Kiszka wrote:
> On 2016-04-12 18:45, git repository hosting wrote:
>> Module: xenomai-3
>> Branch: wip/dovetail
>> Commit: 867070475384652b4e3d4a25f5ad983732a59a7e
>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=867070475384652b4e3d4a25f5ad983732a59a7e
>>
>> Author: Philippe Gerum <rpm@xenomai.org>
>> Date:   Sun Mar 20 17:58:33 2016 +0100
>>
>> lib/cobalt: add config switch to enable lazy setsched update mode
>>
>> --enable-lazy-setsched should be given for enabling lazy propagation
>> of scheduling parameters upon calls to pthread_setschedparam*(),
>> sched_setscheduler(). Defaults to off.
> 
> Missed this so far: Is there particular reason to keep it off by
> default? Regression concerns (i.e. this will be only off in the
> beginning) or downsides of the lazy implementation?

Basically, this is turned off by default because of the weird effects on
the regular glibc behavior due to bypassing the priority cache (e.g.
standard prio protect mutexes). At any rate, people switching this on
must know what they are doing, including the side-effects on the glibc,
and implicitly accept them.

Conversely, people who don't need this option should not have to bother
about those side-effects.

-- 
Philippe.


      reply	other threads:[~2016-04-25 16:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1aq1Ri-0002Ry-RW@sd-51317.xenomai.org>
2016-04-25 15:00 ` [Xenomai] Philippe Gerum : lib/cobalt: add config switch to enable lazy setsched update mode Jan Kiszka
2016-04-25 16:05   ` Philippe Gerum [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=571E4057.7000703@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=jan.kiszka@siemens.com \
    --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.