Date: Fri, 07 Oct 2005 11:16:46 -0400 From: Chuck Swiger <cswiger@mac.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, "Yuriy N. Shkandybin" <jura@networks.ru> Subject: Re: [HEADSUP] big polling changes Message-ID: <4346915E.6040106@mac.com> In-Reply-To: <20051007142107.GD14542@cell.sick.ru> References: <00e401c5cb48$de24e190$6504010a@Jura> <20051007142107.GD14542@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: > On Fri, Oct 07, 2005 at 06:10:26PM +0400, Yuriy N. Shkandybin wrote: > Y> polling + kern.polling.idle_poll=1 > Y> CPU states: 0.2% user, 0.0% nice, 59.3% system, 21.3% interrupt, 19.2% > Y> idle > Y> but about +10 % perfomance thoughput > > This is normal and known for idle_poll. Is this because polling now fires the device interrupt every so often even while idle? If so, could this behavior obtain a threshold to limit the maximum number of interrupts being added when the device is idle? I've been seeing interupt storms back in 5.4, especially when a USB controller and a NIC share an IRQ. Another thing to consider might be to switch in and out of polling mode dynamicly, which would let you operate in interrupt-driven mode if the network is quiet or silent, but would go into polling mode once there is enough traffic to make doing so a benefit. Once you go into polling mode, stay there until the network becomes silent again. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4346915E.6040106>