| |||||||||||||
What about separating locks and data?What about separating locks and data?Posted Jan 4, 2013 17:04 UTC (Fri) by corbet (editor, #1)In reply to: What about separating locks and data? by renox Parent article: Improving ticket spinlocks I'd pondered that a bit as I was writing the article. It would be painful. If you move the lock out of the structure it is protecting, you have to allocate it in a separate step. The allocation could maybe be hidden in spin_lock_init(), but the freeing would require explicit action (in vast numbers of call sites) or some severe magic. Probably don't want to do that. Regardless of whether the lock is relocated or not, the only way to avoid cache problems with surrounding data is to expand the lock to fill an entire cache line. That would bloat spinlocks considerably, and there are a lot of spinlocks in a running kernel. That overhead would hurt; among other things, the bloat, alone, would slow things by causing additional cache utilization. Maybe I'm missing something (I often do), but, from what I can tell, trying to isolate the locks isn't really a viable solution.
(Log in to post comments)
What about separating locks and data? Posted Jan 4, 2013 17:34 UTC (Fri) by renox (subscriber, #23785) [Link]
I agree with you that the management of deallocation is a significant issue/change.
As for the memory bloat, I think that these "separated spinlock" would be useful for only the most contended spinlocks which would somewhat mitigate the issue.
What about separating locks and data? Posted Jan 5, 2013 22:53 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
There will then be the problem of exactly how much space do you allocate for the spinlock
how do you know what the best cache size is to use on the processor that someone will buy next year and run the binary you compiled today on.
What about separating locks and data? Posted Jan 5, 2013 23:50 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Aren't there runtime facilities in the kernel for tailoring behavior to the actual cache line size? Something like a cache line allocator?That would make this kind of memory layout feasible until they invent a more complex form of caching.
What about separating locks and data? Posted Jan 5, 2013 18:07 UTC (Sat) by PaulMcKenney (subscriber, #9624) [Link]
Putting the lock and the data together increases performance at low levels of lock contention. After all, if the lock and data are in separate cache lines, you will take two cache misses, whereas if the lock and data are in the same cache line, you will only take one cache miss.
Of course, and noted earlier in this thread, the opposite holds true at high levels of contention. Life is like that sometimes! ;-)
|
|||||||||||||