User: Password:
|
|
Subscribe / Log in / New account

Eliminating tasklets

Eliminating tasklets

Posted Jun 29, 2007 21:15 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: Eliminating tasklets by arjan
Parent article: Eliminating tasklets

But note that the latency that gets improved is the latency of processing interrupts, not the latency of anything a process does. When you consider that a tasklet can't sleep and runs before the CPU returns to regular process stuff, and limit your view to single CPU systems, it isn't as clear that rescheduling interrupt handling for a different time helps any latency. A program that gets interrupted still is not going to get control back until all that interrupt processing is done.

Here's the latency that gets improved: Consider 10 interrupts of the same class that happen one after another. The first 9 take 1ms to service and nobody's urgently waiting for the result. #10 only takes a microsecond, and if you don't respond within 1ms, expensive hardware will go idle. Without tasklets, those interrupts get serviced in order of arrival, so expensive hardware will be idle for 8 ms. With tasklets, you make the code for 1-9 reschedule their work to tasklets (only takes a microsecond to reschedule) and #10 completes in 10 microseconds, soon enough to keep the expensive hardware busy.


(Log in to post comments)

Eliminating tasklets

Posted Jun 30, 2007 6:47 UTC (Sat) by dlang (subscriber, #313) [Link]

with workqueues it's not the case that all the interrupt related processing must be completed before userspace gets a chance to run again. with tasklets that is the case. so the switch means that a userspace program that's waiting for some data doesn't need to keep getting delayed while the spu is handling other incomeing data.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds