From owner-freebsd-performance@FreeBSD.ORG Thu Oct 21 20:43:38 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E1316A4CF for ; Thu, 21 Oct 2004 20:43:38 +0000 (GMT) Received: from dfmm.org (walter.dfmm.org [66.180.195.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id B70B043D45 for ; Thu, 21 Oct 2004 20:43:38 +0000 (GMT) (envelope-from freebsd-performance@dfmm.org) Received: (qmail 54726 invoked by uid 1000); 21 Oct 2004 20:43:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Oct 2004 20:43:38 -0000 Date: Thu, 21 Oct 2004 13:43:35 -0700 (PDT) From: Jason Stone X-X-Sender: jason@walter To: freebsd-performance@freebsd.org In-Reply-To: <0A85B89D-2369-11D9-BD7C-000A95EFF4CA@foolishgames.com> Message-ID: <20041021133719.S79820@walter> References: <20041020133406.V79820@walter> <0A85B89D-2369-11D9-BD7C-000A95EFF4CA@foolishgames.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: luigi@iet.unipi.it Subject: Re: decreasing interrupt CPU load X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 20:43:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If you look at http://info.iet.unipi.it/~luigi/polling, the last Q & A > question suggests why it is disabled for SMP. It seems that polling > only runs on one thread whereas an smp box might handle concurrently > interupts from different devices. > > Can the scheduler move the thread to another cpu or is it locked on a > particular cpu? thanks for the pointer. it seems to me that the thread doing the polling could move from cpu to cpu, but that's not the issue - the issue, if I'm understanding the author, is that the polling thread will always be a single thread, whereas if we use traditional interrupts, they can be handled on multiple cpu's concurrently. so interrupts, with multiple cpu's to handle them, might give much better performance than a single polling thread. if that's the only issue, then preventing one from compiling with both SMP and DEVICE_POLLING doesn't seem necesary, since you can turn polling on and off at runtime with sysctl's. luigi: does that sound right to you? has any consideration been giving to removing the restriction preventing DEVICE_POLLING from building on an SMP system, in light of the fact that polling can just be turned off if it's giving suboptimal performance? -Jason -------------------------------------------------------------------------- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFBeB95swXMWWtptckRAvlRAJ4806zyUOwMq89qgNKXlbbOE826LQCg6AGW qWDj3u/F4V3a51YJQAA2qpM= =sN26 -----END PGP SIGNATURE-----