From owner-freebsd-current@FreeBSD.ORG Tue Nov 6 10:37:16 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 5BDDB9BF for ; Tue, 6 Nov 2012 10:37:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B016F8FC12 for ; Tue, 6 Nov 2012 10:37:15 +0000 (UTC) Received: (qmail 11571 invoked from network); 6 Nov 2012 12:12:43 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Nov 2012 12:12:43 -0000 Message-ID: <5098E8B4.5040309@freebsd.org> Date: Tue, 06 Nov 2012 11:38:44 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: polling's future [was: Re: Dynamic Ticks/HZ] 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> In-Reply-To: <10806.1352197657@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Luigi Rizzo , Joe Holden , Ryan Stone , 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:37:16 -0000 On 06.11.2012 11:27, Poul-Henning Kamp wrote: > -------- > In message <5098E526.6070101@freebsd.org>, Andre Oppermann writes: > >> Hi Luigi, >> >> do you agree on polling having outlived its usefulness in the light >> of interrupt moderating NIC's and SMP complications/disadvantages? > > Can I just point out, that what we have is not in fact "device-polling" > but only "some-kinds-of-network-interface-polling" ? > > 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 and schedules a dedicated taskqueue thread which then continues to process X as long it comes in? Only after all items have been processed the interrupt is enabled again for the next batch. The effect is hybrid polling. When there is no work the poller doesn't have to run. If work starts coming in the dedicated taskqueue picks up and continues until finished. > Amongst the sensible uses for that would be high-speed serial > interfaces etc. -- Andre