All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: gryma biloy <gryma.biloy@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Is xenomai OK for early boot purpose ?
Date: Mon, 31 Jan 2011 12:14:00 +0100	[thread overview]
Message-ID: <4D469978.8010600@domain.hid> (raw)
In-Reply-To: <AANLkTikz2UuirubwC1oRQoXBRCqWS0xf3z__3mD60rCn@domain.hid>

gryma biloy wrote:
> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>> On Mon, 2011-01-31 at 11:51 +0100, Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> On Mon, 2011-01-31 at 09:55 +0100, gryma biloy wrote:
>>>>> Hello,
>>>>>
>>>>> On a project running Linux on a beagle board, I'd like to add the
>>>>> following capabilities to my platform :
>>>>>   - real time processes with periodic tasks (10ms, 100ms & 200 ms) and
>>>>> a low jitter (< 50 us)
>>>> Kernel space apps then, likely. Userland apps (the recommended way)
>>>> probably have a larger worst-case jitter on this hardware, albeit still
>>>> below 100 us. Gilles?
>>> Las time I checked, latency measured on a 720MHz omap3 was around 55us
>>> with a 1ms period and 35us with a 100us period.
>> Yeah, I suspect that longer periods ( >= 10 ms ) may introduce more
>> opportunities for cache eviction due to linux activity, and therefore
>> higher jittery, even if bounded.
> 
> Does this mean that the main reason for jittery is due to the cache ?
> What would be the other reasons, if any ?

interrupt latency is mainly due to interrupts masking sections in the
kernel, and the time to reach the code of the interrupt handler when an
interrupt is received, including the time it takes to preempt current
context to go to interrupt mode, then to access the hardware to mask/ack
the interrupt.
scheduling latency (of the higher priority task) is bound roughly by
interrupt latency plus the time that it takes to switch context in
kernel-space, plus the time that it takes to return to user-space.

All these paths are made of code which is executed and which access
data, and so which execution time depend on both I-cache and D-cache.

-- 
					    Gilles.


  parent reply	other threads:[~2011-01-31 11:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-31  8:55 [Xenomai-help] Is xenomai OK for early boot purpose ? gryma biloy
2011-01-31 10:32 ` Philippe Gerum
2011-01-31 10:51   ` Gilles Chanteperdrix
2011-01-31 10:53     ` Philippe Gerum
2011-01-31 11:01       ` gryma biloy
2011-01-31 11:12         ` Philippe Gerum
2011-01-31 11:17           ` Gilles Chanteperdrix
2011-01-31 11:22             ` Philippe Gerum
2011-01-31 11:14         ` Gilles Chanteperdrix [this message]
2011-01-31 14:27           ` Gilles Chanteperdrix

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=4D469978.8010600@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=gryma.biloy@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.