Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Nov 2013 10:12:39 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Oliver Pinter <oliver.pntr@gmail.com>
Cc:        Davide Italiano <davide@freebsd.org>, Alexander Motin <mav@freebsd.org>, FreeBSD Stable Mailing List <freebsd-stable@freebsd.org>, "current@freebsd.org" <current@freebsd.org>
Subject:   Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
Message-ID:  <CAJ-Vmok7uC72-a9g-e-UGHMYADpEUgW%2BH4_MB8eC1MBvT9w83Q@mail.gmail.com>
In-Reply-To: <CAPjTQNHi_7vLZvGzA_ad_M8e_X_n-EuLzA8dGsX9t9XP8VdwjA@mail.gmail.com>
References:  <CAPjTQNF5Q=sPaTSpjnwpVOjiM9e70T0ve-GQ71Sv0zHx_Az7dg@mail.gmail.com> <CAJ-Vmokx6iLcNqjPzVB%2BHxsQxN4NaLkV1%2BEGREOsW7SyjqFNcw@mail.gmail.com> <CAPjTQNHi_7vLZvGzA_ad_M8e_X_n-EuLzA8dGsX9t9XP8VdwjA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> wrote:
> op@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@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@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@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe@freebsd.org"
>>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmok7uC72-a9g-e-UGHMYADpEUgW%2BH4_MB8eC1MBvT9w83Q>