Date: Thu, 31 May 2012 18:42:18 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: ULE/sched issues on stable/9 - why isn't preemption occuring? Message-ID: <4FC7915A.8080801@FreeBSD.org> In-Reply-To: <CAJ-VmokXN9Ci8j2ExZkA-U=fsrMmeOn-ULB0pCYdtSwqHWpiKQ@mail.gmail.com> References: <CAJ-VmomWV2XibSNSr5Mfh7mpKsWrX5GKsNfU9iq7TO6%2BKxxQhw@mail.gmail.com> <201205301124.52597.jhb@freebsd.org> <CAJ-VmokXN9Ci8j2ExZkA-U=fsrMmeOn-ULB0pCYdtSwqHWpiKQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/31/12 01:02, Adrian Chadd wrote: > 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.) I've seen penalties from both of them myself on latency-sensitive single-threaded disk benchmark: 17K IOPS instead of 30K IOPS without. Problem with powerd was that CPU load during the test was below powerd idle threshold and it decided to drop frequency, that proportionally increased I/O handling latency. powerd can't know that while average CPU load is now, the request handling latency is critical for the test. About C-states, I've noticed on my tests on Core2Duo system that while ACPI reports equal exit latency for C1 and C2 states of 1us there, they are not really equal -- C2 exit is measurably slower. On newer generations of systems (Core i) I've never seen C2 latency reported as 1us, but instead it has much higher values. Having real big value there system should automatically avoid entering those states under the high interrupt rates to not get penalties. But that is all about latency-sensitive test. I am surprised to see such results for the network benchmarks. Handling packets in bursts should hide that latency. Unless you are loosing packets because of some overflows during these delays. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC7915A.8080801>