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>