From owner-freebsd-questions@FreeBSD.ORG Sat Nov 21 02:07:57 2009 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 549831065670 for ; Sat, 21 Nov 2009 02:07:57 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id DF4D48FC13 for ; Sat, 21 Nov 2009 02:07:56 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (hdl.lariat.net [66.119.58.133]) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA21572; Fri, 20 Nov 2009 19:07:50 -0700 (MST) Message-Id: <200911210207.TAA21572@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Nov 2009 19:07:42 -0700 To: Mel Flynn From: Brett Glass In-Reply-To: References: <200911202135.OAA18537@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: questions@freebsd.org Subject: Re: kern.polling.lost_polls X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 02:07:57 -0000 At 06:25 PM 11/20/2009, Mel Flynn wrote: >So that means that you give the kernel .25 microseconds to poll and act on >any pending network IO. That's probably not enough. I think that you mean ".25 milliseconds," not ".25 microseconds," above. >It is further explained by >the >comment in sys/kern/kern_poll.c: >/* > * Hook from hardclock. Tries to schedule a netisr, but keeps track > * of lost ticks due to the previous handler taking too long. > * Normally, this should not happen, because polling handler should > * run for a short time. However, in some cases (e.g. when there are > * changes in link status etc.) the drivers take a very long time > * (even in the order of milliseconds) to reset and reconfigure the > * device, causing apparent lost polls. > * > * The first part of the code is just for debugging purposes, and tries > * to count how often hardclock ticks are shorter than they should, > * meaning either stray interrupts or delayed events. > */ Well, even at HZ=2000, kern.polling.lost_polls and kern.polling.suspect are both incrementing, as is kern.polling.stalled: stargate# sysctl -a | grep polling kern.polling.burst: 150 kern.polling.burst_max: 150 kern.polling.each_burst: 5 kern.polling.idle_poll: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 20 kern.polling.short_ticks: 0 kern.polling.lost_polls: 41229 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 2 kern.polling.enable: 0 kern.polling.phase: 0 kern.polling.suspect: 31653 kern.polling.stalled: 10 kern.polling.idlepoll_sleeping: 1 hw.acpi.thermal.polling_rate: 10 But if I slow the clock down to 1000 Hz, it's unclear if the machine will be able to keep up with traffic. I was already getting more than 1,000 network interrupts per second before I tried polling, and I'm not sure how many packets the interfaces (some fxp, some em) can buffer up. I'm going to try it, but if it doesn't work I will have to go back to interrupt-driven operation. --Brett Glass