From owner-freebsd-current@FreeBSD.ORG Mon Nov 5 16:16:02 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 CED7DA05; Mon, 5 Nov 2012 16:16:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 864ED8FC17; Mon, 5 Nov 2012 16:16:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 621267300A; Mon, 5 Nov 2012 17:36:54 +0100 (CET) Date: Mon, 5 Nov 2012 17:36:54 +0100 From: Luigi Rizzo To: Ryan Stone Subject: Re: Dynamic Ticks/HZ Message-ID: <20121105163654.GA12870@onelab2.iet.unipi.it> References: <509758B8.1000409@rewt.org.uk> <50975F6F.6010907@rewt.org.uk> <5097898C.9080109@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Joe Holden , 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: Mon, 05 Nov 2012 16:16:03 -0000 On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: > On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: > > > doh, running kernel wasn't as GENERIC as I thought it was, looks like > > device polling not only breaks dynamic ticks but also reduces rx ability > > significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without > > > > Is this a known issue? (and if device polling isn't as useful as it once > > was, should it be removed?) > > > > Device polling on modern multiqueue NICs isn't very useful because you're > limited to a single thread for handling packets. I have a patch that fixes > this that I've let fall by the wayside. the 150,000 is result of the combination of the default value of sysctl kern.polling.burst_max and kern.polling.idle_poll=0 (i think this is the default value for the latter). The 150 was sized for the peak pps on a 100Mbit/s interface, back in 2001. You should at least be able to raise the number and see what kind of throughput you can achieve. This said, modern nics also have interrupt moderation so you don't really need polling. cheers luigi