Date: Mon, 9 Jan 2006 13:37:57 -0500 From: Ed Maste <emaste@phaedrus.sandvine.ca> To: nielsen@memberwebs.com Cc: freebsd-hackers@freebsd.org Subject: Re: Polling for devices other than NICs [patch] Message-ID: <20060109183756.GA14717@sandvine.com> In-Reply-To: <20060107231659.DD05BDCA9A5@mail.npubs.com> References: <20060106022920.BF7DADCA990@mail.npubs.com> <20060107231659.DD05BDCA9A5@mail.npubs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 07, 2006 at 11:17:00PM +0000, Nate Nielsen wrote: > Nate Nielsen wrote: > > The polling functionality in FreeBSD is currently a bit NIC centric. > > With a few changes other types devices can use the polling subsystem. > > Attached is my first whack at this. > > > > This is some of my first hacking on the FreeBSD kernel. It'd be great if > > there was someone who could take a look and help me get it right. > > Attached is a patch against HEAD. This looks like a good start to expanding polling beyond network interfaces, but it doesn't address the fact that the polling code currently has a single feedback parameter, shared by all devices, to control the amount of work done in each handler. Passing the count parameter to devices other than network interfaces implies that their drivers should do roughly as much work as a network interface would to process that number of packets. If the other devices take too long per count then polling-enabled network interfaces will end up without enough CPU time to do their required work. In addition, the current polling algorithm breaks down when you get to very high CPU utilization by the stack (e.g. if acting as a high bandwidth router). This happens because it adds one count per tick if the polling did not run longer than one hardclock interval, but brings it down to 7/8ths if it did. This ends up producing a sawtooth effect in the amount of work done by the polling handlers. Andre Oppermann is performing some high-perf stack testing, and he ran into this effect; in polling mode the maximum packet rate was achieved while there was still idle CPU time. I have a proof of concept patch that modifies the polling feedback algorithm to measure the amount of time spent in the polling handlers, and then attempt to schedule an appropriate amount of work to fill out the time slot. Andre is going to be testing it out shortly. Don't get me wrong, I think your patch is a step in the right direction, but we do have more work to do in order to completely generalize the polling code. (By the way, it seems some of your driver diffs move the *_poll functions around, making it harder to see what you actually changed. It would be better to leave the functions where they already are, I think.) -Ed Maste
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060109183756.GA14717>