Date: Wed, 20 Oct 2004 23:08:19 +0200 From: Uwe Doering <gemini@geminix.org> To: freebsd-performance@freebsd.org Subject: Re: decreasing interrupt CPU load Message-ID: <4176D3C3.30007@geminix.org> In-Reply-To: <006701c4b6e4$ab133d20$b3db87d4@multiplay.co.uk> References: <004001c4b69d$80e21f40$0c0210ac@ADMIN1><41766350.4080901@centtech.com> <006001c4b6ad$38a8cac0$0c0210ac@ADMIN1> <4176C7A8.6030407@geminix.org> <006701c4b6e4$ab133d20$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Steven Hartland wrote:
>> Since you mentioned earlier that you run this on an SMP system, are
>> you aware that device polling is available only for single CPU
>> kernels, that is, not in SMP mode? This is poorly documented,
>> unfortunately. You can find out about it by looking at the first
>> couple of lines of 'sys/kern/kern_poll.c'.
>
> Actually it does work quite well on an SMP machine if you comment said
> lines out :)
I wonder, can you define how well "quite well" actually is? I mean,
it's of course everyone's own decision, but I wouldn't dare to do this
on a production system. Is there a statement on this available from the
author of the code? One should think that he must have had a reason for
explicitly disabling device polling for SMP. Maybe locking issues (race
conditions)?
Uwe
--
Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org | http://www.escapebox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4176D3C3.30007>