On 2025-12-18 17:16, Boqun Feng wrote: [...]
I would suggest we make CONFIG_PREEMPT_HAZPTR always enabled hence no need for a config, do we have the measurement of the additional cost?
Removing the PREEMPT_HAZPTR brings read-side performance from 13.1 down to 5.1 ns. So there is a surprising amount of work that goes into list_add/list_del. I just noticed that I was running a kernel with CONFIG_LIST_HARDENED=y. Reruning refscale for PREEMPT_HAZPTR=y with list hardening disabled goes from 13.1 ns to 12.4ns, so not a huge win. I did not notice much difference in terms of scheduler performance with a quick hackbench run, but I cannot claim it is an extensive benchmark in any way.
I think you need to add interrupt disabling for chain/unchain because of the potential readers in interrupt and then you can avoid the preempt disabling in hazptr_release() I think. Let's aim for supporting readers in interrupt handler, because at least lockdep needs that.
OK, I'll look into it! Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
