|
|
Log in / Subscribe / Register

hazptr_synchronize() cost

hazptr_synchronize() cost

Posted Jul 28, 2026 23:36 UTC (Tue) by neilbrown (subscriber, #359)
Parent article: Hazard pointers for the kernel

I wonder if this implementation is trying to be too general.

It provides a single arena were pointers can be registered, and where other threads can check if a given address is registered. This area has at least 4 slots per CPU that need to be searched, and if you are lucky enough to have 1024 CPUs, then that is a lot of slots probably spread over several NUMA nodes.

But any particular use case I can think of involves a particular module that is only interested in its own pointers, and so would be happy with its own smallish arena that can quickly be searched. That would mean that registering a pointer would not be cpu-local and so would need atomic operations, but hazptr_synchronize() could have a smaller maximum cost in the uncontended case.

But maybe the developers of this functionality have thought about this for more than the half-hour that I have spent on it. Does anyone know of any discussion about the expected cost of hazptr_synchronize() and the tradeoffs with hazptr_acquire() cost?


The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds