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. > What I-pipe patch version are you using? > 2.6.33-arm-1.18-00 > > 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. > 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? > > -- > Gilles. >
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
