4

I was looking at this pic: enter image description here

and have 2 questions regarding it: 1. how much faster should a disk be in order for polling to be refered over the interrupt?

I thought that beacuse of the ISR and the process jumping (when using interrupt) - that polling will be better when using fast SSD for example , where the polling takes less time than the the interrupt(ISR+ scheduler ). Am I mistaken?

and the second question is : If my disk is slower than the SSD in my first question, but still fast - is there any reason to prefer polling?

I was wondering if the fact that I'll have lot's of I/O - read requests is a good enough reaon to prefer polling.

thanks!

user1386966
  • 3,302
  • 13
  • 43
  • 72
  • I can only speak in general, but most devices these days don't generate all that many interrupts, they queue up requests from the driver, do much of the logic themselves and generate an interrupt only at completion of one or more requests. Unless you're talking embedded systems, polling very seldom makes sense. – Joachim Isaksson May 24 '13 at 16:55
  • Don't forget to accept my response if it answered your question! Thanks. – Dan Jun 20 '13 at 07:28

1 Answers1

6

You could imagine a case where the overhead of running interrupt handlers (invalidating your caches, setting up the interrupt stack to run on) could be slower than actually doing the read or write, in which case I guess polling would be faster.

However, SSDs are fast compared to disk, but still much slower than memory. SSDs still take anywhere from tens of microseconds to milliseconds to complete each I/O, whereas doing the interrupt setup and teardown uses all in-memory operations and probably takes a maximum of, say, 100-1000 cycles (~100ns to 1us).

The main benefit of using interrupts instead of polling is that the "disabled" effect of using interrupts is much lower, since you don't have to schedule your I/O threads to continuously poll for more data while there is none available. It has the added benefit that I/O is handled immediately, so if a user types a key, there won't be a pause before the letter appears on the screen while the I/O thread is being scheduled. Combining these issues is a mess - inserting arbitrary stalls into your I/O thread makes polling less resource-intense at the expense of even slower response times. These may be the primary reasons nobody uses polling in kernel I/O designs.

From a user process' perspective (using software interrupt systems such as Unix signals), either way can make sense since polling usually means a blocking syscall such as read() or select() rather than (say) checking a boolean memory-mapped variable or issuing device instructions like the kernel version of polling might do. Having system calls to do this work for us in the OS can be beneficial for performance because the userland thread doesn't get its cache invalidated any more or less by using signals versus any other syscall. However this is pretty OS dependent, so profiling is your best bet for figuring out which codepath is faster.

Dan
  • 7,155
  • 2
  • 29
  • 54
  • 2
    While not exactly incorrect, I wanted to update this (after gaining 7 years more experience :-P). The primary latency problem with interrupts is thread hops, which add usually tens of microseconds into your IO path. So if you’re using an SSD with read latencies as low as 20us and write latencies as low as 150us, you might take a 2x latency hit on reads / 15% penalty on writes, assuming you only do one thread hop. There are also newer, faster devices like 3dXpoint that have even lower latencies. So in effect nearly all low latency block storage products use polling some of the time these days. – Dan Jun 12 '20 at 00:59
  • 2
    Also, many use pinned user space threads to do the IO, to avoid context switching between kernel and user space (and avoid having to build everything in the kernel). – Dan Jun 12 '20 at 01:00