From owner-freebsd-current@FreeBSD.ORG Tue Nov 6 10:46:30 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 2E4E9BC3; Tue, 6 Nov 2012 10:46:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CF3F78FC08; Tue, 6 Nov 2012 10:46:29 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id AC0598A3FC; Tue, 6 Nov 2012 10:46:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qA6AkSVb010891; Tue, 6 Nov 2012 10:46:28 GMT (envelope-from phk@phk.freebsd.dk) To: Andre Oppermann Subject: Re: polling's future [was: Re: Dynamic Ticks/HZ] In-reply-to: <5098E8B4.5040309@freebsd.org> From: "Poul-Henning Kamp" References: <509758B8.1000409@rewt.org.uk> <50975F6F.6010907@rewt.org.uk> <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> Date: Tue, 06 Nov 2012 10:46:28 +0000 Message-ID: <10890.1352198788@critter.freebsd.dk> Cc: Davide Italiano , Ryan Stone , Joe Holden , Luigi Rizzo , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:46:30 -0000 -------- 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.