Re: [BISECTED] 2.6.35.*: horrible (exponential? >linear) slowdown to unusability (HPET)

[Jiri Slaby <jirislaby@gmail.com>]

On 09/10/2010 10:37 AM, Thomas Gleixner wrote:
> On Fri, 10 Sep 2010, Nix wrote:
> 
>> On 10 Sep 2010, Artur Skawina spake thusly:
>>> I'm seeing this too, except here it happens every couple of days of uptime,
>>> lasts for a few minutes, and then goes away. Which made bisecting a bit
>>> impractical... Thank you for doing it. 
>>
>> I just happened to be the lucky sod for whom it was consistently going
>> wrong. :)
>>
>>> HW is similar; x64 and X58/82801JI/ICH10, tsc clocksrc.
>>> Did that printk trigger?
>>
>> No.
>>
>> (hm, odd.
>>
>> spindle:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>>
>> spindle:~# grep -i tsc /proc/timer_list
>> spindle:~# grep -i hpet /proc/timer_list
>> Clock Event Device: hpet
>>  set_next_event: hpet_legacy_next_event
>>  set_mode:       hpet_legacy_set_mode
>>
>> I suspect current_clocksource doesn't do what we think it does, or the
>> clocksource and 'clock event device' are not the same.)
> 
> Right, they are not the same. clocksource provides us a read out
> device for timekeeping (usually a simple increasing counter). clock
> event device is used to generate timer interrupts.
> 
> HPET provides both functionalities.
> 
> The patch you bisected is affecting the clock events part of the
> HPET. So yes, it's not a clock source problem.

AFAIU, clocksource=jiffies shouldn't fix this issue. If that's the case
we have another 2.6.32->2.6.33 regression (and I will report it
separately). People report the system is unusable (sleepers are not
woken), unless clocksource=jiffies, clocksource=tsc or nolapic_timer is
used or a key pressed (i.e. some HW interrupt):
https://bugzilla.novell.com/show_bug.cgi?id=579932
(there is also a report with 2.6.35.3 vanilla)

thanks,
-- 
js