All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Schwab <schwab@domain.hid>
To: xenomai@xenomai.org, Markus.Franke@domain.hid
Subject: Re: [Xenomai-help] measuring context switch primary<->secondary mode
Date: Thu, 30 Nov 2006 11:19:01 +0100	[thread overview]
Message-ID: <200611301119.01173.schwab@domain.hid> (raw)
In-Reply-To: <456D5075.1060905@domain.hid>

On Wednesday 29 November 2006 10:18, Markus Franke wrote:
> Dear Xenomai Users,
>
> I want to measure the context switch times between primary and secondary
>  execution modes. Therefore I made some small modifications to the
> already present Latency-Test located in
> $(XENOMAI_ROOT)/src/testsuite/latency
>
> Basically I just changed few things in the latency-Task:
>
> ---snip---
>
> err = rt_task_wait_period(&ov);
> before_tsc = rt_timer_tsc();
> printf("This is a teststring for entering in secondary mode!\n");
> after_tsc = rt_timer_tsc();
>
> dt = after_tsc - before_tsc;
>
>
> if (dt > maxj)
>     maxj = dt;
> if (dt < minj)
>     minj = dt;
> sumj += dt;
>
> ---snap---
>
> After that I configured a kernel with CONFIG_PREEMPT and one without. In
> theory I should resolve much lower switch-times when I am running the
> kernel with CONFIG_PREEMPT, right? However, I can't prove this theory.
> The Switch-Times in the non-CONFIG_PREEMPT case are a bit lower than in
> the CONFIG_PREEMPT - Case.
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.

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. This probability might be very close to zero.

Ulrich
-- 
====================================================
  inmess GmbH
  Frankfurter Str. 74
  D - 64521 Gross-Gerau
  Phone: +49 6152 97790
  Fax  : +49 6152 977920
  mail : info@domain.hid
  web:   www.inmess.de
====================================================


  parent reply	other threads:[~2006-11-30 10:19 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 [this message]
2006-11-30 13:48   ` Markus Franke
2006-11-30 14:04     ` Jan Kiszka
     [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=200611301119.01173.schwab@domain.hid \
    --to=schwab@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.