Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

What about separating locks and data?

Posted Jan 4, 2013 17:34 UTC (Fri) by renox (subscriber, #23785)
In reply to: What about separating locks and data? by corbet
Parent article: Improving ticket spinlocks

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.
Of course contention isn't the same on all the systems and developers working on embedded or supercomputers would probably disagree on which spinlocks has to be "separated"..

(Log in to post comments)

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.