Date: Thu, 31 May 2012 12:52:52 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Alexander Motin <mav@freebsd.org> Subject: Re: ULE/sched issues on stable/9 - why isn't preemption occuring? Message-ID: <CAJ-VmomyGohc28d5EOCXCh5kYdTY4T3fRLcYDnNnonoa0HKG3w@mail.gmail.com> In-Reply-To: <201205311055.27648.jhb@freebsd.org> References: <CAJ-VmomWV2XibSNSr5Mfh7mpKsWrX5GKsNfU9iq7TO6%2BKxxQhw@mail.gmail.com> <201205301124.52597.jhb@freebsd.org> <CAJ-VmokXN9Ci8j2ExZkA-U=fsrMmeOn-ULB0pCYdtSwqHWpiKQ@mail.gmail.com> <201205311055.27648.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 May 2012 07:55, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday, May 30, 2012 6:02:15 pm Adrian Chadd wrote: >> Hi, >> >> I've re-run the test with powerd and sleep state stuff disabled - lo >> and behold, UDP tests are now up around 240-250MBit, what I'd expect >> for this 2 stream 11n device. >> >> So why is it that I lose roughly 80MBit of throughput with powerd and >> C2/C3 enabled, when there's plenty of CPU going around? The NIC >> certainly isn't going to sleep (I've not even added that code.) > > Why do you not expect that? =A0I would try, btw, just disabling powerd fo= r now > and leaving C2/C3 enabled to see if that makes a difference. I expected it because I didn't know what else is going on. Thanks to your braindumping in this thread, I now have a much better appreciation for the issues here. :-) > As to my first question, with powerd enabled and an otherwise idle machin= e, > powerd may very well be running your CPU at some rediculously low speed (= like > 100 Mhz) pretty much all the time. =A0Do you really think you could push = more > than 80 MBit with a 100 MHz CPU? This is with the power connected, so powerd seems to leave the CPU at full speed. I'll have to double-check. > Secondly, just having a lot of CPU isn't enough if you don't have it quic= kly. > Latency matters, too. =A0Take a look at your C2/C3 info like so: > > dev.cpu.0.cx_supported: C1/3 C2/59 C3/93 > > IIRC, the last number is the number of microseconds the CPU takes to resu= me > from an interrupt. =A0So, on this box (a Core i5), it can take 93 us afte= r an > interrupt occurs during C3 before the CPU will get around to executing th= e > first instruction. =A0It might be worse on your machine. Ok. I'll check the latency values when I'm back at home. The default bootup too is to use the ACPI idle routine, Even with powerd disabled and sleep limited to C1, I still see the TSC mismatch issues. I've modified my kernel to default to using spin at bootup. I'll see if this fixes the TSC mismatch when doing KTR traces. Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomyGohc28d5EOCXCh5kYdTY4T3fRLcYDnNnonoa0HKG3w>