Hi Mathieu, On Thu, Dec 18, 2025 at 07:21:28PM -0500, Mathieu Desnoyers wrote: > 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! >
Gentle ping on this. I want to make some forward progress on this ;-) I suggest we make PREEMPT_HAZPTR enabled by default and support readers in interrupt handler. The rest missing part is an async thread, we could utilize some code in my previous patchset [1]. Let me know whether you think you have the cycle for this, otherwise I could add this into your series ;-) Thanks! [1]: https://lore.kernel.org/lkml/[email protected]/ Regards, Boqun > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com
