Re: [PATCH] Add an offset in the cyc2ns computation to fix sched_clock jumps

["Guillaume Chazarain" <guichaz@gmail.com>]

2007/3/18, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>:
> Hi Guillaume,

Hi Mathieu, thanks for your extensive reply.

> yet another level of band-aid over a

I don't agree it's a band-aid, changing the scaling coefficient
without adjusting an offset is a bug.

> broken architecture : AMD 7th and 8th generations

Actually in my case it's Intel Pentium M Dothan.

> other parts of the kernel suffers from those TSC inconsistencies

These other parts should not use sched_clock() but the clocksource
mechanism which in my case rightly avoids the TSC and uses the
ACPI timer. And I hope it will stay that way as the TSC definitely is
not a reliable time source in my case for the reasons you gave.

> it does not deal with frequency scaling due to temperature related
> events, and does not, as I recall, deal with frequency scaling in halt
> mode.

Yep, I saw this, that's why I said in this case sched_clock() does not
return nanoseconds as it thinks it does. Thankfully, the scheduler is
not stressed when the CPU is idle. Anyway, spilling on another thread,
this is a bonus point for the RSDL scheduler as it does not account
the sleeping time of tasks.

> I also plan to update this global last_tsc every timer tick to give a
> higher bound to time accuracy.

Then I don't see how this is significantly better than the ACPI timer
except for the increased precision in short durations. For example,
my CPU can lower its frequency down to 798 MHz and the TSC
down to 350 MHz or so (measured). So your clock will think the
TSC runs at 798 MHz  when it runs at 350MHz, and every tick the
clock will make a half tick jump to catch up with its delay.

The best solution seems to buy a new computer with a reliable
TSC ;-)

Thanks.

-- 
Guillaume