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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911210207.TAA21572>