Hello,
I have just upgraded kernel (2.6.16.x->2.6.18.1) on on of my servers (Dell
PowerEdge1425SC with 2 CPUs with HT - total 4 CPUs) and noticed that
system no longer uses HPET as a clocksource.
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies hpet tsc pit
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
AFAIK TSC should not be used on SMP systems, shouldn't it?
Best regards,
Krzysztof Ol?dzki
On Wed, 2006-10-18 at 21:32 +0200, Krzysztof Oledzki wrote:
> Hello,
>
> I have just upgraded kernel (2.6.16.x->2.6.18.1) on on of my servers (Dell
> PowerEdge1425SC with 2 CPUs with HT - total 4 CPUs) and noticed that
> system no longer uses HPET as a clocksource.
>
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> acpi_pm jiffies hpet tsc pit
>
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
Yep. You'll notice the hpet is still available, but by default we select
the TSC (unless it is marked as unstable).
> AFAIK TSC should not be used on SMP systems, shouldn't it?
This was done to unify the behavior between i386 and x86_64. Previously
i386 was overly cautious, selecting the TSC only if ACPI PM, or HPET
were not available. However this impacted performance as the TSC is much
faster. In fact, many distros reversed the order to prefer the TSC.
It has been asserted that many Intel SMP systems can safely use the TSC,
while AMD smp boxes for the most part cannot. On any system, if the
system enters C3, or we notice cpufreq changes in the TSC, it will be
disqualified and it will fall back to the hpet or the next best
available clocksource. Hopefully this will always select the best
clocksource.
Please do let us know if you see any problems due to this change.
thanks
-john