Re: [RFC PATCH v4 4/4] hazptr: Migrate per-CPU slots to backup slot on context switch
Mathieu Desnoyers <[email protected]> Mon, 23 Feb 2026 14:40:59 -0500
| Newsgroups | dev.linux.lists.lkmm,org.kernel.vger.linux-kernel,org.kernel.vger.rcu,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
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