From: Jan Kiszka <jan.kiszka@domain.hid>
To: Markus.Franke@domain.hid
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] measuring context switch primary<->secondary mode
Date: Thu, 30 Nov 2006 15:04:28 +0100 [thread overview]
Message-ID: <456EE4EC.5050305@domain.hid> (raw)
In-Reply-To: <456EE120.5060003@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
Markus Franke wrote:
> Ulrich Schwab wrote:
>> I think that CONFIG_PREEMPT should reduce the jitter of Your measurement, most
>> importantly the worst case switch time, for wich You need a long test run
>> under heavy load.
>> CONFIG_PREEMPT is there to provide more determinism, which usually has a price
>> in performance.
>> Realtime is about determinism not performance (or speed).
>> Its not maximum speed but guaranteed minimum speed.
>
> You are absolutely right. I put my system under some load (dd) and made
> two tests. One was with CONFIG_PREEMPT and one without. The worst case
> switch time jitter was about 30% lower in the CONFIG_PREEMPT case, so
> your prediction was right.
>
>> Since the probability of a preemption during the mode switch without
>> CONFIG_PREEMPT is lower, it might take a long time until the worst case mode
>> switch time is observed.
>
> Sorry but I don't understand what you are meaning. Let me explain my
> point of view. When a realtime task in the Xenomai-Domain makes a
> linux-systemcall the task is migrated fully automatically to the
> Linux-Domain as soon as we reach the next preemption point in the
> Linux-Kernel. Due to the fact that preemptability of the linux-kernel
> increase when using CONFIG_PREEMPT, the time to the next preemption
> point should decrease, right? I don't get the point of your last sentence.
Exactly. We see several preemption issues in secondary mode: first to
get the requested service running (i.e. preempt the currently executed
Linux job), second to avoid that it is involuntarily preempted, and
third to get over potentially congested locks quickly.
CONFIG_PREEMPT helps here to reduce the worst case (PREEMPT_RT even
more, but it currently collides with patching the kernel). On the other
hand, it increases the overhead for your Linux subsystem (check with
lmbench e.g.). Still, depending on what you need, you are able to tune
Linux'es own preemption model freely when using Xenomai and I-pipe.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2006-11-30 14:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 9:18 [Xenomai-help] measuring context switch primary<->secondary mode Markus Franke
2006-11-29 9:54 ` Gilles Chanteperdrix
2006-11-29 11:40 ` Markus Franke
2006-11-30 10:19 ` Ulrich Schwab
2006-11-30 13:48 ` Markus Franke
2006-11-30 14:04 ` Jan Kiszka [this message]
[not found] ` <456EE9C4.6000203@domain.hid>
2006-11-30 15:34 ` Jan Kiszka
2006-11-30 14:30 ` Ulrich Schwab
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=456EE4EC.5050305@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Markus.Franke@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.