Date: Sat, 21 Nov 2009 08:10:14 -0900 From: Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net> To: Brett Glass <brett@lariat.net> Cc: questions@freebsd.org Subject: Re: kern.polling.lost_polls Message-ID: <b491a0c45ff8b78fcd75239b31bd1c9b@sbmail.office-on-the.net> In-Reply-To: <200911210207.TAA21572@lariat.net> References: <200911202135.OAA18537@lariat.net> <db2308c2d90148218fcc9209721b9920@sbmail.office-on-the.net> <200911210207.TAA21572@lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Nov 2009 19:07:42 -0700, Brett Glass <brett@lariat.net> wrote:
> At 06:25 PM 11/20/2009, Mel Flynn wrote:
>=20
>>So that means that you give the kernel .25 microseconds to poll and act
on
>>any pending network IO. That's probably not enough.
>=20
> I think that you mean ".25 milliseconds," not ".25 microseconds," above=
.
Yes, sorry. It should be enough, but...it's related to CPU speed and numb=
er
of interfaces. On FreeBSD-net they can give you better advice, most notab=
ly
whether all 6 interfaces are done in one poll and so each task needs to b=
e
completed within 1/HZ/N? I cannot say this with certainty.
>>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 trie=
s
>> * to count how often hardclock ticks are shorter than they should,
>> * meaning either stray interrupts or delayed events.
>> */
>=20
> Well, even at HZ=3D2000, kern.polling.lost_polls and=20
> kern.polling.suspect are both incrementing, as is kern.polling.stalled:
>=20
> 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
That bugs me: if you have 6 devices, the number of handlers should be
6.
/*
* Try to register routine for polling. Returns 0 if successful
* (and polling should be enabled), error code otherwise.
* A device is not supposed to register itself multiple times.
*
* This is called from within the *_ioctl() functions.
*/
Unless this should really read "drivers", but I think it's devices.
> 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
>=20
> But if I slow the clock down to 1000 Hz, it's unclear if the=20
> machine will be able to keep up with traffic. I was already getting=20
> more than 1,000 network interrupts per second before I tried=20
> polling, and I'm not sure how many packets the interfaces (some=20
> fxp, some em) can buffer up. I'm going to try it, but if it doesn't=20
> work I will have to go back to interrupt-driven operation.
You might be able if your network architecture allows it, to bring down
the task load by increasing the MTU and enable jumbo frames.
>From em(4):
Support for Jumbo Frames is provided via the interface MTU setting.
Selecting an MTU larger than 1500 bytes with the ifconfig(8) utility
con=E2=80=90
figures the adapter to receive and transmit Jumbo Frames. The maximu=
m
MTU size for Jumbo Frames is 16114.
--=20
Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b491a0c45ff8b78fcd75239b31bd1c9b>