Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
On Tuesday, November 05, 2013 3:14:22 pm Oliver Pinter wrote: hmm, and seems like, the bottleneck are not in geom or cam, but in em driver or in networking stack the scenario is: A machine: dd if=/dev/ada1 bs=1M | nc -l B machine: nc IP | dd of=/dev/null bs=1M hmm, when dd-ing from /dev/zero and switch back to idletick to 0, then the performance of network dropped from 113MByte/s to 70+/-15 MByte/s machdep.idle_mwait=1/0 has no effect machdep.idle=htl has no effect machdep.idle=hlt is the same thing as only using C1 (C1 is just the 'hlt' instruction). Try machdep.idle=spin perhaps? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
.. the main reason to use machdep.idle=hlt is that it is a different code path. But to ensure you're always going via the hlt codepath, you _first_ have to disable mwait. The idle code first decides whether to run mwait or idle, then if it doesn't choose mwait, it chooses machdep.idle. That's why you first have to disable idle_wait. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
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-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
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.p...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
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 adr...@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.p...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
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.p...@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 adr...@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.p...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
and sysctl machdep.idle_mwait=0 -adrian On 5 November 2013 10:12, Adrian Chadd adr...@freebsd.org wrote: 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.p...@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 adr...@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.p...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
On 11/5/13, Adrian Chadd adr...@freebsd.org wrote: 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? quad core, i5-4670 How about changing the idle loop from acpi to hlt, see if that fixes things? (Without tweaking the event timer logic.) Now, after reboot, the problem has gone. The other symptom are: on vt switching is laggish, and switching the num lock state delayed ~0.5sec. This are reproducible ~ every 10-15th boot. 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.p...@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 adr...@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.p...@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-unsubscr...@freebsd.org dmesg.i5-4670 Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
dmesg corrected On 11/5/13, Oliver Pinter oliver.p...@gmail.com wrote: On 11/5/13, Adrian Chadd adr...@freebsd.org wrote: 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? quad core, i5-4670 How about changing the idle loop from acpi to hlt, see if that fixes things? (Without tweaking the event timer logic.) Now, after reboot, the problem has gone. The other symptom are: on vt switching is laggish, and switching the num lock state delayed ~0.5sec. This are reproducible ~ every 10-15th boot. 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.p...@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 adr...@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.p...@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-unsubscr...@freebsd.org dmesg-i5-4670-10-STABLE Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer
hmm, and seems like, the bottleneck are not in geom or cam, but in em driver or in networking stack the scenario is: A machine: dd if=/dev/ada1 bs=1M | nc -l B machine: nc IP | dd of=/dev/null bs=1M hmm, when dd-ing from /dev/zero and switch back to idletick to 0, then the performance of network dropped from 113MByte/s to 70+/-15 MByte/s machdep.idle_mwait=1/0 has no effect machdep.idle=htl has no effect On 11/5/13, Oliver Pinter oliver.p...@gmail.com wrote: dmesg corrected On 11/5/13, Oliver Pinter oliver.p...@gmail.com wrote: On 11/5/13, Adrian Chadd adr...@freebsd.org wrote: 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? quad core, i5-4670 How about changing the idle loop from acpi to hlt, see if that fixes things? (Without tweaking the event timer logic.) Now, after reboot, the problem has gone. The other symptom are: on vt switching is laggish, and switching the num lock state delayed ~0.5sec. This are reproducible ~ every 10-15th boot. 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.p...@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 adr...@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.p...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
