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 9999 B machine: nc IP 9999 | 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.pntr_at_gmail.com> wrote: > dmesg corrected > > On 11/5/13, Oliver Pinter <oliver.pntr_at_gmail.com> wrote: >> On 11/5/13, Adrian Chadd <adrian_at_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.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" >>>>> >>> >> >Received on Tue Nov 05 2013 - 19:14:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC