Messages in this thread | | | Subject | Re: [PATCH v2] bit_spinlock: introduce smp_cond_load_relaxed | From | Gao Xiang <> | Date | Tue, 6 Nov 2018 19:36:41 +0800 |
| |
Hi Peter,
On 2018/11/6 19:00, Peter Zijlstra wrote: >>> Yes, that's much better. Ideally though, we'd get rid of bit spinlocks >>> that have significant enough contention for this to matter. >> OK, I will send v3 to fix like the above. > That's not answering the full question though. What bit spinlocks did > you find where this matters? And can't we convert them to proper > spinlocks instead?
I just misunderstood your question and I get your point now.
"What bit spinlocks did you find where this matters?" nope..I said the original background to Greg before, that is I tried to use smp_cond_load_relaxed instead of busy spining in the development of erofs file system and I saw this bit_spinlock implementation by chance...This is not a big modification but since I raised the question before and I want to trace to the end...
"And can't we convert them to proper spinlocks instead?" I think bit_spinlock is sometime preferred since it requires little memory and can be integrated into some fields(eg. flags)...It is selectable for spinlocks don't have to many users at the same time, so I think it depends on the detailed real use scenerio... It is just a tool for user code to select case by case... That is my personal idea...
IMO, to use wrapped up function for the detailed scenario could be better than open-coded all the time (eg. do cpu_relax(); while(...)) since it could be optimizated even more for the specific architecture...
Thanks, Gao Xiang
| |