Eric Eric wrote:
> On Sat, Apr 23, 2011 at 5:41 PM, Gilles Chanteperdrix <
> [email protected]> wrote:
>
>> Eric Eric wrote:
>>> Hello, I've asked a lot of questions here and gotten very prompt and
>> helpful
>>> responses, so I summarized them in a FAQ since I figure others may have
>>> similar questions. See http://ericrebates.zzl.org/xen_faq.txt . If
>> this
>>> seems useful maybe someone can append them to the end of the wiki FAQ.
>> I am not sure all questions really are really that frequent, but yes, we
>> should add some to the FAQ. Would you be willing to do it? If yes, I
>> will give you write access to the wiki.
>>
>
> Sure. Maybe the best approach is to create a link from the FAQ to an LFAQ
> (less frequently asked questions) so as not to add a bunch of questions that
> don't apply to most people.
>
>
>>> On another note, I have been comparing Xenomai's context switch latency
>> to
>>> GHS Integrity. I found that on average Xenomai seems to take three times
>> as
>>> long to context switch versus Integrity (12uS vs. 4uS) running almost
>>> identical test code. Does anyone know why this may be or how to reduce
>> this
>>> latency in Xenomai? Since it appears Gilles helped implement the fast
>>> context switching extension for the Linux kernel, I'm assuming Xenomai is
>>> also taking advantage of this extension.
>> I assume you are measuring context switch times in kernel-space, then
>> FCSE will not help you, FCSE helps for MMU context switches.
>
>
> Right, didn't think about that. I suppose FCSE will also not help with
> context switches between threads of the same process either.
>
>
>> And if you
>> are testing on omap3, FCSE is not implemented for omap3. Do you have
>> unlocked context switch enabled ?
>>
>
> Unlocked context switch is enabled.
Disabling it will reduce the context switch time.
>
>
>> What I-pipe patch version are you using?
>>
>
> 2.6.33-arm-1.18-00
There was no big changes for omap, but you should use the latest (1.18-02).
>
>
>> You can probably reduce a bit the time by using rt_timer_tsc() or even
>> xnarch_get_cpu_tsc() to do the measurements, then rt_timer_tsc2ns after
>> the second measurement, but I am afraid you will not go as low as 4us.
>>
>
> I will try this although I doubt it will have much impact. I say that
> because I also used rtdm_clock_read_monotonic to benchmark mutex lock/unlock
> cycles, and got down to 2uS in that measurement, which seems to imply that
> the overhead of rtdm_clock_read_monotonic is small compared to 12uS.
Well, I would not call 2us small compared to 12us. But yes 12 - 2 is
still far from 4us.
>
>
>> You can also try and enable the I-pipe tracer to see where the time is
>> spent, but beware of the time dilation...
>>
>
> This seems like an interesting idea. What is the time dilation issue?
The tracer introduces a sizeable overhead especially on ARM.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
