[10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer

Adrian Chadd adrian at freebsd.org
Tue Nov 5 18:12:40 UTC 2013


Ok, so it's only hitting C1. It's not going into C2.

Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?

How about changing the idle loop from acpi to hlt, see if that fixes
things? (Without tweaking the event timer logic.)

I'm worried that what you're seeing here are missed interrupts or
interrupts that aren't immediately causing the driver thread to be
scheduled (and thus things enter HLT until the next interrupt.) I had
to deal with this crap on MIPS for quite some time.

sysctl machdep.idle=hlt



-adrian


On 5 November 2013 09:25, Oliver Pinter <oliver.pntr at gmail.com> wrote:
> op at perpetua ~> sysctl dev.cpu
> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.CPU0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.coretemp.delta: 59
> dev.cpu.0.coretemp.resolution: 1
> dev.cpu.0.coretemp.tjmax: 100.0C
> dev.cpu.0.coretemp.throttle_log: 0
> dev.cpu.0.temperature: 41.0C
> dev.cpu.0.freq_levels: 3401/84000 3400/84000 3200/77169 3000/70587
> 2800/64262 2700/61182 2500/55201 2300/49464 2100/43946 1900/38654
> 1700/34277 1500/29407 1400/27053 1225/23671 1200/22509 1050/19695
> 1000/18167 875/15896 800/14031 700/12277 600/10523 500/8769 400/7015
> 300/5261 200/3507 100/1753
> dev.cpu.0.cx_supported: C1/1/1 C2/2/67
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% 0.00% last 812us
> dev.cpu.1.%desc: ACPI CPU
> dev.cpu.1.%driver: cpu
> dev.cpu.1.%location: handle=\_PR_.CPU1
> dev.cpu.1.%pnpinfo: _HID=none _UID=0
> dev.cpu.1.%parent: acpi0
> dev.cpu.1.coretemp.delta: 56
> dev.cpu.1.coretemp.resolution: 1
> dev.cpu.1.coretemp.tjmax: 100.0C
> dev.cpu.1.coretemp.throttle_log: 0
> dev.cpu.1.temperature: 44.0C
> dev.cpu.1.cx_supported: C1/1/1 C2/2/67
> dev.cpu.1.cx_lowest: C1
> dev.cpu.1.cx_usage: 100.00% 0.00% last 1348us
> dev.cpu.2.%desc: ACPI CPU
> dev.cpu.2.%driver: cpu
> dev.cpu.2.%location: handle=\_PR_.CPU2
> dev.cpu.2.%pnpinfo: _HID=none _UID=0
> dev.cpu.2.%parent: acpi0
> dev.cpu.2.coretemp.delta: 61
> dev.cpu.2.coretemp.resolution: 1
> dev.cpu.2.coretemp.tjmax: 100.0C
> dev.cpu.2.coretemp.throttle_log: 0
> dev.cpu.2.temperature: 39.0C
> dev.cpu.2.cx_supported: C1/1/1 C2/2/67
> dev.cpu.2.cx_lowest: C1
> dev.cpu.2.cx_usage: 100.00% 0.00% last 845us
> dev.cpu.3.%desc: ACPI CPU
> dev.cpu.3.%driver: cpu
> dev.cpu.3.%location: handle=\_PR_.CPU3
> dev.cpu.3.%pnpinfo: _HID=none _UID=0
> dev.cpu.3.%parent: acpi0
> dev.cpu.3.coretemp.delta: 62
> dev.cpu.3.coretemp.resolution: 1
> dev.cpu.3.coretemp.tjmax: 100.0C
> dev.cpu.3.coretemp.throttle_log: 0
> dev.cpu.3.temperature: 38.0C
> dev.cpu.3.cx_supported: C1/1/1 C2/2/67
> dev.cpu.3.cx_lowest: C1
> dev.cpu.3.cx_usage: 100.00% 0.00% last 1609us
>
> On 11/5/13, Adrian Chadd <adrian at freebsd.org> wrote:
>> Hi!
>>
>> Can you do 'sysctl dev.cpu' please? I'd like to see what sleep
>> state(s) your CPU is entering.
>>
>> Thanks!
>>
>>
>> -adrian
>>
>>
>> On 5 November 2013 06:07, Oliver Pinter <oliver.pntr at gmail.com> wrote:
>>> Hi all!
>>>
>>> The machine is a Haswell machine, the disc performance was very poor
>>> (20-30MByte/sec).
>>> When I change the kern.eventtimer.idletick from 0 to 1, the normal
>>> performance restored back to normal (70-90MByte/sec).
>>>
>>> The default eventtimer was LAPIC.
>>>
>>> On other machine Q9300, this was fully reproducible.
>>> _______________________________________________
>>> freebsd-current at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe at freebsd.org"
>>


More information about the freebsd-stable mailing list