Date: Thu, 21 Oct 2004 10:53:32 -0700 From: Sean Chittenden <sean@chittenden.org> To: lukem.freebsd@cse.unsw.edu.au Cc: freebsd-performance@freebsd.org Subject: Re: CPU utilisation cap? Message-ID: <1F92711A-238A-11D9-9171-000A95C705DC@chittenden.org> In-Reply-To: <Pine.LNX.4.61.0410211419480.8238@wagner.orchestra.cse.unsw.EDU.AU> References: <Pine.LNX.4.61.0410211419480.8238@wagner.orchestra.cse.unsw.EDU.AU>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am measuring idle time using a CPU soaker process which runs at a > very low priority. Top seems to confirm the output it gives. > > What I see is strange. CPU utilisation always peaks (and stays) at > between 80 & 85%. If I increase the amount of work done by the UDP > echo program (by inserting additional packet copies), CPU utilisation > does not rise, but rather, throughput declines. The 80% figure is > common to both the slow and fast PCI cards as well. > > This is rather confusing, as I cannot tell if the system is IO bound > or CPU bound. Certainly I would not have expected the 133/64 PCI bus > to be saturated given that peak throughput is around 550Mbit/s with > 1024-byte packets. (Such a low figure is not unexpected given there > are 2 syscalls per packet). There are two things that come to mind. The first being a patch that should have been applied in time for 5.2, but I forget the timing of the releases. http://lists.freebsd.org/mailman/htdig/cvs-src/2003-October/012628.html IIRC, there was another commit that made a similar change specifically in the handling of UDP packets, such that it used a TAILQ append instead of traversing a linked list. For some reason I think this happened after 5.2, but I'm not able to find high nor low of the commit and could be pulling said memory into existence. Too many commits to keep track of. Recently rwatson has been doing a bunch of testing of our UDP stack and has also committed a fair number of fixes. He likely has many words of wisdom on what's changed or not right in 5.2.1. Regardless, I wager that if you give RELENG_5_3 a shot, I bet you'd find performance to be less surprising. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1F92711A-238A-11D9-9171-000A95C705DC>