| |||||||||||||
KS2011: Preemption disable and verifiable APIsKS2011: Preemption disable and verifiable APIsPosted Oct 25, 2011 15:56 UTC (Tue) by valyala (guest, #41196)Parent article: KS2011: Preemption disable and verifiable APIs
Why not splitting per-CPU data further into per-thread data? At least this_thread_*() functions will be safe in thread contexts without any locking. Access to per-thread data is guaranteed to be fast unless the thread is recently migrated to another CPU.
(Log in to post comments)
KS2011: Preemption disable and verifiable APIs Posted Oct 26, 2011 8:39 UTC (Wed) by etienne (subscriber, #25256) [Link]
Or maybe get a pointer to a per-cpu structure at the beginning of your treatment and continue to use this pointer anyway, even if the processor has been changed under your foot.
Most of the time the processor will not be changed, so you get the speed, but anyway the code is always right, just in some rare cases slower.
KS2011: Preemption disable and verifiable APIs Posted Oct 26, 2011 16:56 UTC (Wed) by valyala (guest, #41196) [Link]
>> Or maybe get a pointer to a per-cpu structure at the beginning of your treatment and continue to use this pointer anyway, even if the processor has been changed under your foot.
This won't work if you are going to modify the per-cpu structure after the CPU has been changed. So you'll end up with either locking or atomic modifications for the structure. But since most of the time the structure is modified via native CPU, both locking and atomic modifications should be fast, because there is no cache line bouncing.
KS2011: Preemption disable and verifiable APIs Posted Oct 26, 2011 22:10 UTC (Wed) by BenHutchings (subscriber, #37955) [Link]
I think this would make thread creation a lot more expensive.
KS2011: Preemption disable and verifiable APIs Posted Oct 27, 2011 0:10 UTC (Thu) by rusty (✭ supporter ✭, #26) [Link]
Generally num-cpus is small, num-threads is huge.
KS2011: Preemption disable and verifiable APIs Posted Oct 27, 2011 9:33 UTC (Thu) by valyala (guest, #41196) [Link]
I suppose the number of threads, which usually access per-CPU data, is comparable to the number of CPUs. So, per-thread data can be created lazily in order to avoid performance and memory hit for each created thread.
KS2011: Preemption disable and verifiable APIs Posted Nov 3, 2011 1:00 UTC (Thu) by slashdot (guest, #22014) [Link]
Yeah, I wonder whether this could indeed be the right solution for preempt-rt kernels.
Instead of disabling migration or adding potentially contended locks, just making per-cpu data per-thread should work naturally.
KS2011: Preemption disable and verifiable APIs Posted Nov 14, 2011 2:32 UTC (Mon) by mfedyk (guest, #55303) [Link]
You are assuming that you have process context, which in the kernel is there less often than many realize.
|
|||||||||||||