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...


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to