Jan Kiszka wrote: > Philippe Gerum wrote: >> Jim Cromie wrote: >>> Philippe Gerum wrote: >>> >>>> Gilles Chanteperdrix wrote: >>>> >>>>> Philippe Gerum wrote: >>>>> > Redone the check here on a Centrino 1.6Mhz, and still have >>>>> roughly x20 > improvement (a bit better actually). I'm using >>>>> Debian/sarge gcc 3.3.5. >>>>> >>>>> I think I remember that Pentium M has a much shorter mull instruction >>>>> than other processors of the family. >>>>> >>>> That would explain. Anyway, as John Stulz put it: >>>> "math is hard, lets go shopping!" >>>> >>> Heh. Appropriate that his name (Stultz) comes up here, as his >>> generic-time (GTOD) >>> patchset looks headed for 2.6.18, bringing with it a full re-working >>> of linux timers / timeofday. IN this new world, time is kept on >>> free-running counters. >>> >>> Ive been running this patchset on my soekris for some time, since >>> GTOD detects that the TSC counts slowly, calls it insane, and does timing >>> with the PIT. >>> >>> With GTOD, writing a new clocksource driver is easy, enough so I could >>> do it. >>> My clocksource patch uses the 27 mhz timer on the Geode CPU. >>> Once the TSC is de-rated, mine becomes the best clocksource, and GTOD >>> switches to it. >>> >>> All of which is to say .. >>> new mainline code is coming, should this current rework notion wait, >>> given that its will all need revisited again later >>> >> Clearly yes, since this is going to impact Adeos too. GTOD is going to >> fiddle with the PIT channels in a way Adeos needs to be aware of, in >> order for the client RTOS to reuse such timer. Added to the flow of >> other core changes planned for 2.6.18, this is likely going to be funky. >> >> "Find wall. Beat head against same." >> > > May not be required: the GTOD and clocksource abstractions could provide > a clean way to register some virtual, Adeos- or RTOS-provided clock with > Linux. And that clock may even lose ticks without Linux losing its > system time! So far for the theory, practice may still require walls... >
Some refinement: clocksource may either remain TSC or become a Xenomai-provided clock if its handling (PIT...) requires synchronisation. The clockevent, the one thing that triggers timer IRQs, could become a virtual device driven by Xenomai. And GTOD should happily make use of them instead of messing up with shared hardware. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
