From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 11:16:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C4FBA5C; Sun, 11 Nov 2012 11:16:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8092B8FC0A; Sun, 11 Nov 2012 11:16:23 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id qABBGEHw087203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Nov 2012 12:16:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id qABBGBQZ005210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 12:16:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id qABBGB2j007906; Sun, 11 Nov 2012 12:16:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id qABBGAOM007905; Sun, 11 Nov 2012 12:16:10 +0100 (CET) (envelope-from ticso) Date: Sun, 11 Nov 2012 12:16:10 +0100 From: Bernd Walter To: Poul-Henning Kamp Subject: Re: polling's future [was: Re: Dynamic Ticks/HZ] Message-ID: <20121111111609.GA7814@cicely7.cicely.de> References: <5097898C.9080109@rewt.org.uk> <20121105163654.GA12870@onelab2.iet.unipi.it> <5097E880.8010001@rewt.org.uk> <20121105165748.GA13098@onelab2.iet.unipi.it> <5098E526.6070101@freebsd.org> <10806.1352197657@critter.freebsd.dk> <5098E8B4.5040309@freebsd.org> <10890.1352198788@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10890.1352198788@critter.freebsd.dk> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Davide Italiano , Joe Holden , Andre Oppermann , FreeBSD Current , Luigi Rizzo , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 11:16:25 -0000 On Tue, Nov 06, 2012 at 10:46:28AM +0000, Poul-Henning Kamp wrote: > -------- > In message <5098E8B4.5040309@freebsd.org>, Andre Oppermann writes: > > >> I think it should go away, and if there still is a relevant > >> usage segment, be replaced by _real_ "device-polling" which is > >> not tied to the network stack. > > > >Don't we already have the equivalent with a fast interrupt thread > >that simply acknowledges and disables the interrupt [...] > > The point is that not all hardware have interrupt-pacing, so > being able to poll at a lower rate in software would save overhead. > > I'm not sure if the hardware where this applies is still relevant, > it would probably be mostly in the embedded space. I've used polling on embedded systems to avoid userland starvation and not to gain bandwidth. Interrupts have priority over userland processes and with a CPU not capable to handle say 100MBit/s ethernet interrupt load you can't even login via console console. With polling such a machine is way more responsive and allow people to find out that there is a saturated link before pulling the plug. There are likely other solutions, but it worked well for that puprose. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.