Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
I suspect that the latencies they are concerned about are those caused by processing more items without releasing the lock, not those caused by waiting to fill up a batch.
LSFMM: Lock scaling
Posted Apr 25, 2013 7:55 UTC (Thu) by dlang (✭ supporter ✭, #313)
This latency is bounded by setting the max batch size.
But unless you allow for items to be re-ordered, allowing batching will greatly decrease latency for most items, because it gets more work done.
In addition, in many cases you don't need to hold the lock for the entire time you are working on something.
for example, in rsyslog the threads delivering logs out lock the main queue, mark what messages they are working on, unlock the queue, work on the message, then lock the queue to mark the messages as completed (and unlock the queue as they are done)
The old way where the output threads locked the queue, processed one message, unlocked the queue and repeated meant that the queue was locked for a much larger percentage of the time, and a lot of CPU time was spent on lock contention issues
appropriate batching (and adjustment of data structures) can work wonders with this sort of problem.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds