All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Seeger <steven.seeger@flightsystems.net>
To: "Meng, Fino" <fino.meng@intel.com>, Evl <evl@evlproject.org>,
	xenomai@xenomai.org
Cc: Philippe Gerum <rpm@xenomai.org>
Subject: Re: Dovetail <-> PREEMPT_RT hybridization
Date: Thu, 23 Jul 2020 09:09:31 -0400	[thread overview]
Message-ID: <4555996.GXAFRqVoOG@omoikane> (raw)
In-Reply-To: <b4c53b27-3de9-3264-0a3f-0563f95321ec@xenomai.org>

On Tuesday, July 21, 2020 1:18:21 PM EDT Philippe Gerum wrote:
> 
> - identifying and quantifying the longest interrupt-free sections in the
> target preempt-rt kernel under meaningful stress load, with the irqoff
> tracer. I wrote down some information [1] about the stress workloads which
> actually make a difference when benchmarking as far as I can tell. At any
> rate, the results we would get there would be crucial in order to figure
> out where to add the out-of-band synchronization points, and likely of some
> interest upstream too. I'm primarily targeting armv7 and armv8, it would be
> great if you could help with x86.

So from my perspective, one of the beauties of Xenomai with traditional IPIPE 
is you can analyze the fast interrupt path and see that by design you have an 
upper bound on latency. You can even calculate it. It's based on the number of 
cpu cycles at irq entry multiplied by the total numbers of IRQs that could 
happen at the same time. Depending on your hardware, maybe you know the 
priority of handling the interrupt in question.

The point was the system was analyzable by design.

When you start talking about looking for long critical sections and adding 
sync points in it, I think you take away the by-design guarantees for latency. 
This might make it less-suitable for hard realtime systems.

IMHO this is not any better than Preempt-RT. But maybe I am missing something. 
:)

Steven





  parent reply	other threads:[~2020-07-23 13:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20 20:47 Dovetail <-> PREEMPT_RT hybridization Philippe Gerum
2020-07-20 22:44 ` Paul
2020-07-21  8:18   ` Philippe Gerum
2020-07-21  8:39     ` Paul
2020-07-21  9:25       ` Philippe Gerum
2020-07-21  9:43         ` Paul
2020-07-21  9:46           ` Philippe Gerum
2020-07-21  5:26 ` Meng, Fino
2020-07-21 17:18   ` Philippe Gerum
2020-07-22 12:26     ` Meng, Fino
2020-07-23 13:09     ` Steven Seeger [this message]
2020-07-23 16:23       ` Philippe Gerum
2020-07-23 21:53         ` Steven Seeger

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=4555996.GXAFRqVoOG@omoikane \
    --to=steven.seeger@flightsystems.net \
    --cc=evl@evlproject.org \
    --cc=fino.meng@intel.com \
    --cc=rpm@xenomai.org \
    --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.