Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Jun 2004 14:15:44 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Jon Noack <noackjr@alumni.rice.edu>
Cc:        luigi@iet.unipi.it
Subject:   Re: Device polling
Message-ID:  <Pine.NEB.3.96L.1040613141040.9835B-100000@fledge.watson.org>
In-Reply-To: <40CC97E0.5010003@alumni.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 13 Jun 2004, Jon Noack wrote:

> On 06/11/04 03:05, Magnus Carlebj=F6rk wrote:
> > Hi. I have been using Luigi's polling code extensively i several multip=
rocessor
> > systems for over a year now, and it works flawlessly and efficiently. N=
icely
> > done Luigi!
> >=20
> > 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 I=
S
> > compatible with SMP, it just does not utilize all of it's features.
>=20
> 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)=
=20
> 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.=20

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@fledge.watson.org      Senior Research Scientist, McAfee Research



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040613141040.9835B-100000>