Device polling

[Robert Watson]

On Sun, 13 Jun 2004, Jon Noack wrote:

> On 06/11/04 03:05, Magnus Carlebjörk wrote:
> > Hi. I have been using Luigi's polling code extensively i several multiprocessor
> > systems for over a year now, and it works flawlessly and efficiently. Nicely
> > done Luigi!
> > 
> > In the beginning of /usr/src/sys/kern/kern_poll.c there are a few lines thas
> > says that polling is incompatible with SMP. This is not true, polling IS
> > compatible with SMP, it just does not utilize all of it's features.
> 
> I just tested this on my SMP all-in-one home server (Web, Mail, NFS,
> Samba, Squid, etc.).  It's been up for over 24 hours with no apparent
> issues.  The machine is used pretty heavily, with NFS mounted home
> directories and CVS mirror (see below) -- a CVS update of the src tree
> over NFS has done a good job of breaking fragile setups in the past.
> Everything seemed OK.  That said, peak performance (as tested by iperf) 
> took a nosedive: with 32-bit em adapters (gige), tcp bandwidth dropped
> from over 360Mbps to around 200 Mbps.  If anyone has any suggestions for
> more in-depth testing, I'd be willing to try them.  If I have the time I
> may also try the latest netperf patch and see how that affects things. 

I have some thoughts on applying polling in a post-netperf world,
including using multiple polling threads and binding interfaces to
particular threads to reduce potential ordering problems (and possibly
also lock contention).  The 20040613 netperf patch drop appears to have
abuild nit following my merges last night; I'll regen a 20040613a patch
sometime this afternoon, which will also be post-altq-integration.  I'm
not sure it will help your environment, though -- and I've not really
explored the impact of fine-grained locking with polling as yet.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research