Date: Tue, 02 Aug 2005 14:45:30 -0400 From: Chuck Swiger <cswiger@mac.com> To: freebsd@celestial.com Cc: victor@vmpbg.com, freebsd-questions@freebsd.org Subject: Re: polling decreases throughput ~50% Message-ID: <42EFBF4A.2010209@mac.com> In-Reply-To: <20050802173421.GA34971@alexis.mi.celestial.com> References: <200508021537.26986.victor@vmpbg.com> <20050802173421.GA34971@alexis.mi.celestial.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Campbell wrote:
> On Tue, Aug 02, 2005, Victor Semionov wrote:
[ ... ]
>>I was uploading some large file to my neighbor's windows box. With polling
>>disabled, the transfer rate was 8 MB/s and CPU usage was 90%. I turned on
>>polling with sysctl and CPU usage decreased to 50%, which I expected, but
>>also the transfer rate dropped to 4.5 MB/s, about half. The numbers are
>>approximate. The interface is a RealTek (rl driver). No background jobs were
>>running. kern.polling.* all defaults.
What is kern.hz set to? Does increasing it improve throughput?
>> Why is that? I thought polling should decrease CPU usage by avoiding too many
>> context switches when a hw irq is generated frequently, but it shouldn't make
>> the transfer slower if there are no other jobs running.
You have to poll often enough to keep the pipe full, otherwise your max
throughput can be limited. Also, rl hardware isn't the greatest and probably
requires a lot more CPU than a device with working buffer/DMA design.
> I certainly don't claim to be an expert on this subject so take this with a
> grain of salt.
>
> Interrupts were originally created to eliminate the need for polling
> allowing processes to sleep until an interrupt occurs rather than having
> the process in a loop testing to see if any input is ready or the device is
> available for further work.
Blocking was created to eliminate the need for polling/sitting in a loop
testing a condition. Interrupts were created to take the CPU away from normal
processing in order to attend a high-priority, time-critical condition or
signal which can't wait.
A good serial chip/UART, or a NIC receiving packets, shouldn't fire an
interrupt just because a character/packet came in, they should fire an
interrupt when their SILO/buffer is getting full or has some data which hasn't
been serviced in a while. ("Interrupt coalescing")
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42EFBF4A.2010209>