-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements to LFHT #26
base: master
Are you sure you want to change the base?
Conversation
Hi! Sorry last month was really busy. Are you closing this because of inactivity or because those changes are not relevant anymore ? |
First, a hung resize loop when out of memory. Next, non-atomic use of resize_initiated which resulted in resize stopping completely when a queued work item was run too soon.
Just one pointer to buckets is needed in the mmap backend and often less than 64 pointers are needed in the order backend (unless "infinite").
A few initial comments on the PR:
For the mutex leak, please describe which code path appears to leak it. For the variable size cds_lfht, we should consider using a flexible array at the end if the size is now truly variable. |
There was a bug in one of my commits found in pre-prod testing. Before fixing it I closed the PR because I was not sure how many more are there. |
The earliest commit adds error checking to the memory allocations done by cds_lfht_new, so that NULL is returned instead of triggering an assertion. For compatibility with existing apps I've sprinkled public functions with assert(ht). As for resizes, they are now interrupted when out of memory. This is not perfect--the table may remain too small for too long--but better than dumping core.
Another commit reduces the size of struct cds_lfht. These things matter to me as my application creates tons of hash tables dynamically.
Two more commits pertain to call_rcu and workqueue. One fixes a mutex leak on FreeBSD (I gather the mutex is not needed there at all). Another one is a minor tweak to set cpu affinity as early as possible, not 255 iterations later.