From owner-freebsd-net Tue Mar 12 2:28: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B2B1A37B433 for ; Tue, 12 Mar 2002 02:28:02 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g2CARsX52489; Tue, 12 Mar 2002 02:27:54 -0800 (PST) (envelope-from rizzo) Date: Tue, 12 Mar 2002 02:27:54 -0800 From: Luigi Rizzo To: Alain Thivillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: DEVICE_POLLING and kern.polling.{suspect,lost_polls} Message-ID: <20020312022754.B52398@iguana.icir.org> References: <20020312081017.GT276@roadrunner.rominet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020312081017.GT276@roadrunner.rominet.net> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The short reply is that you have nothing to worry about. The long reply is this: short_ticks can happen when there is some system activity that causes timer interrupts to occur later or earlier than they should. I haven't found out why this happens (there are multiple possible reasons), but it does happen, and it is independent of polling -- you see them on any FreeBSD system. lost_polls is a normal event. It occurs sometimes because of the way the polling scheduler works, and it is handled correctly by the software. "suspect" counts some strange events where a netisr is not properly dispatched. I suspect a bug somewhere in the system, not related to polling (maybe some missing "volatile" declaration or some race condition). Normally this bug is harmless, because schednetisr is normally invoked even if there is already a pending netisr. Polling tries to optimise this by not scheduling a netisr if there is already a pending one, but this bug would cause a stall. So i have implemented a workaround which quickly detects the problem, flags it and recovers from it. The fix does not cause any performance problem, though of course I'd like to know why the netisr sometimes is not dispatched... cheers luigi On Tue, Mar 12, 2002 at 09:10:17AM +0100, Alain Thivillon wrote: > Hello, > > This morning i turned on polling (as in -STABLE of yesterday) on a > firewall box running ipfilter. From now everything looks good (but most > of users are coming only after 10 AM UTC ...), but i already have: > > kern.polling.lost_polls: 557 > kern.polling.suspect: 468 > > (with ~ 200 000 routed datagrams) > > This in on a fxp driver, with vlan enabled. > > On another box (connected only to 512Kbits adsl network with pppoe) > running polling for one week i see: > > kern.polling.short_ticks: 1158 > kern.polling.lost_polls: 13710 > kern.polling.suspect: 13603 > > What exactly mean these variables ? Should i worry ? > > -- > A. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message