Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Nov 2009 19:07:42 -0700
From:      Brett Glass <brett@lariat.net>
To:        Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net>
Cc:        questions@freebsd.org
Subject:   Re: kern.polling.lost_polls
Message-ID:  <200911210207.TAA21572@lariat.net>
In-Reply-To: <db2308c2d90148218fcc9209721b9920@sbmail.office-on-the.net>
References:  <200911202135.OAA18537@lariat.net> <db2308c2d90148218fcc9209721b9920@sbmail.office-on-the.net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?200911210207.TAA21572>