Philippe Gerum wrote: > On Thu, 2007-05-03 at 18:44 +0200, Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >>> On Thu, 2007-05-03 at 17:07 +0200, Gilles Chanteperdrix wrote: >>> >>> That was not my point. My point was: don't stuff huge semi-random values >>> into /proc/xenomai/latency to work around terrible jittery especially >>> when porting Xenomai over new platforms, because this is _likely_ the >>> sign of something going wrong elsewhere. >>> >>> E.g. An oldish 90Mhz classic pentium exhibits ~25 us core latency >>> figures with Xenomai; some ARM hw may require more because of >>> unfortunate memory sub-systems, but in any case, you have to >>> _understand_ (e.g. using the tracer) why it is so, first. >> I agree. I still have to see for myself why these damned ARMs have such >> high latencies. >> > > Stelian might jump in as well, but IIRC, a problem we saw on the > Integrator was due to the cost of TLB flushing upon switch_mm with hw > interrupts off. As a consequence of this, even regular Linux operations > would induce jittery for the real-time domain, since enabling hw > interrupts while invalidating is a no-go (actually, it's a go, even a > jump, but out of the window, to be precise...).
May I throw in my, granted, rough idea of establishing coloured caches again? There should exist some older work for Linux already (no cite at hand :(). $Someone would have to analyse its practicability and the chances to reserve certain colours for RT apps. Then one could make any dynamic colour owner change (inside Linux) preemptible by Xenomai because the latter will never need to flush TLB entries at all nor will collide with Linux used colours. Just nice theory, I never looked at real HW nor code yet. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
