From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Xenomai help <xenomai@xenomai.org>, Karl Tyss <tyss.k@domain.hid>
Subject: Re: [Xenomai-help] IRQ-Latency when in idle State on ARM
Date: Fri, 05 Jun 2009 21:08:34 +0200 [thread overview]
Message-ID: <4A296D32.2080003@domain.hid> (raw)
In-Reply-To: <4A295F43.9090904@domain.hid>
Gilles Chanteperdrix wrote:
> Karl Tyss wrote:
>> Right before the cpu is put to sleep by cp15 the I-cache is being disabled in
>> the idle task. I took this part out. So I leave the I-cache enabled when the
>> cpu goes into the idle mode. I suppose that there is a reason for disabling
>> the cache. I will ask my wise ARM book on monday. If this issue doesn't belong
>> here (xenomai list) just say a word :)
>
> Yes, you probably can not do that. You will find the answer in the
> documentation for the arm926EJS core, since this file only concerns this
> core.
>
> On the other hand, as Bosko suggested, if you use the nohlt kernel
> option, you will avoid the idle function altogether, and the I-cache
> will not be disabled then re-enabled.
Note that the effect you observe is due to the very special nature of
your setup: since you run no significant user-space load, the irq
handling function may remain in the cache, but on a realistically loaded
system, the irq handling function will not be able to remain in the
cache, so, the disabling of the I-cache in the idle function will not
change anything with regard to the worst case latency.
Also note that using a GPIO to assess the timer interrupt latency is a
bad idea: if you want to assess the timer interrupt you should register
a timer, because the path in the kernel is different for the timer
interrupt than for other interrupts and especially for multiplexed GPIO
interrupts. But doing all this by yourself and risking to have problem
that we already solved is not a good idea; what you should really do is
use the latency test provided by Xenomai. It is relatively simple,
covers all the cases, and is validated on many platforms.
--
Gilles.
next prev parent reply other threads:[~2009-06-05 19:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A294F59020000F80002DC0E@msw.eppendorf.de>
[not found] ` <200906051932.16827.karl.tyss@domain.hid>
2009-06-05 18:09 ` [Xenomai-help] IRQ-Latency when in idle State on ARM Gilles Chanteperdrix
2009-06-05 19:08 ` Gilles Chanteperdrix [this message]
2009-06-06 17:38 ` Karl Tyss
2009-06-06 18:00 ` Gilles Chanteperdrix
2009-06-05 17:36 Karl Tyss
[not found] <4A28F029020000F80002DB14@domain.hid>
[not found] ` <4A28FAD4020000F80002DB27@domain.hid>
2009-06-05 9:00 ` Karl Tyss
2009-06-05 9:31 ` Gilles Chanteperdrix
2009-06-05 9:56 ` Karl Tyss
2009-06-05 11:10 ` Gilles Chanteperdrix
2009-06-05 13:42 ` Gilles Chanteperdrix
2009-06-05 14:09 ` Karl Tyss
2009-06-05 14:16 ` Gilles Chanteperdrix
2009-06-05 14:17 ` Gilles Chanteperdrix
2009-06-05 14:49 ` Karl Tyss
2009-06-05 15:01 ` Gilles Chanteperdrix
2009-06-05 12:13 ` Bosko Radivojevic
2009-06-08 7:31 ` Karl Tyss
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=4A296D32.2080003@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=tyss.k@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.