Date: Tue, 6 Jan 2004 20:23:01 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Alexander Langer <alex@big.endian.de> Cc: freebsd-net@freebsd.org Subject: Re: Polling CPU usage Message-ID: <20040106200131.H3026@gamplex.bde.org> In-Reply-To: <20040105164216.GD9148@fump.kawo2.rwth-aachen.de> References: <05bc01c3c48f$d47cec30$02c0a8c0@gnbuero.qhintra.net> <20040105164216.GD9148@fump.kawo2.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jan 2004, Alexander Langer wrote: > Also sprach Markus Oestreicher (m.oe@x-trader.de): > > > Is there a way to get the real processor usage including > > the time spent on polling? 1. No. 2. Use kernel profiling (preferably high resolution kernel profiling). Measurement will affect the usage significantly but it should be possible to get a good idea of the usage provided it is small. 3. Record timestamps on entry and exit in the profiling routines and analyze them. This is what high resolution kernel profiling does, except it records timestamps in _all_ routines and this costs more. 4. Use -current and put all the polling routines in low priority threads if they are not already (poll_idle already is, and it may be the most important one here -- in RELENG_4, the time spent doing work in the idle loop is counted as purely idle time and is indistinguishable from time spent doing nothing in the idle loop). This will also record timestamps on entry and exit to the profiling routines, but in a very inefficient way. > What machine do you use? > When bridging approx. 25 MB/s (so 200 MBit/s; 1 MB of traffic roughly > estimates to 1500 packets here) on a Duron 700 with ~2800 ipfw rules > in polling mode, we have ~15.0 system load, so it might be your load > is actually in fact so low ;) real/user/sys times don't give the overhead here, since most of it may be in "idle" time. > I once did a timed buildworld when the system was saturated like this, > and compared to an almost idle CPU (in the night with < 100 kb/s) the > build only took 5% longer or so. This is another way, but it will affect the usage a lot unless buildworld is your main application. buildworld should have no idle time on a perfectly tuned machine (with very fast disks), so polling should rarely occur in idle time. It will have to compete with buildworld and might end up not getting done, so all the network traffic might be handled at interrupt time. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040106200131.H3026>