lkml.org 
[lkml]   [2013]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Allow block drivers to poll for I/O instead of sleeping
On 6/23/13 3:09 AM, Ingo Molnar wrote:
> If an IO driver is implemented properly then it will batch up requests for
> the controller, and gets IRQ-notified on a (sub-)batch of buffers
> completed.
>
> If there's any spinning done then it should be NAPI-alike polling: a
> single "is stuff completed" polling pass per new block of work submitted,
> to opportunistically interleave completion with submission work.
>
> I don't see where active spinning brings would improve performance
> compared to a NAPI-alike technique. Your numbers obviously show a speedup
> we'd like to have, I'm just wondering whether the same speedup (or even
> more) could be implemented via:
>
> - smart batching that rate-limits completion IRQs in essence
> + NAPI-alike polling
>
> ... which would almost never result in IRQ driven completion when we are
> close to CPU-bound and while not yet saturating the IO controller's
> capacity.
>
> The spinning approach you add has the disadvantage of actively wasting CPU
> time, which could be used to run other tasks. In general it's much better
> to make sure the completion IRQs are rate-limited and just schedule. This
> (combined with a metric ton of fine details) is what the networking code
> does in essence, and they have no trouble reaching very high throughput.

Networking code has a similar proposal for low latency sockets using
polling: https://lwn.net/Articles/540281/

David


\
 
 \ /
  Last update: 2013-06-24 00:41    [W:0.157 / U:1.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site