On 2026-02-23 11:54, Boqun Feng wrote:
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 ;-)
Thanks for the ping, I was focused on other things. I do have an updated
branch to post.
I suggest we make PREEMPT_HAZPTR enabled by default and support readers
in interrupt handler.
Yes, that's what I have in my updated branch.
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!
If that's OK with you, I could post my updated hazptr series for
feedback, and leave the async thread adaptation to you.
Thanks,
Mathieu
[1]: https://lore.kernel.org/lkml/[email protected]/
Regards,
Boqun
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
