Messages in this thread | | | Date | Sun, 18 Mar 2007 23:09:11 +0100 | From | "Guillaume Chazarain" <> | Subject | Re: [PATCH] Add an offset in the cyc2ns computation to fix sched_clock jumps |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |