-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Add some more metrics to the pooling allocator #11789
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
base: main
Are you sure you want to change the base?
Add some more metrics to the pooling allocator #11789
Conversation
This commit adds a few more metrics to the `PoolingAllocatorMetrics` type along the lines of accounting for more items as well as the unused slots in the pooling allocator. Notably the count of unused memory and table slots is exposed along with the number of bytes which are kept resident in these slots despite them not being in use. This involved a bit of plumbing to thread around the number of bytes that are actually kept resident to some more locations but is otherwise a pretty straightforward plumbing of accounting information we already had internally.
self.stripes | ||
.iter() | ||
.map(|i| i.allocator.unused_warm_slots()) | ||
.sum() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I avoided this iteration + locking out of a (I guess probably irrational) fear of contention under heavy parallel load. Is that a pretty negligible concern here? If not, should we make a note about it in the pub method docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a note yeah. My prediction is that it won't be too costly, but if it ends up causing problems we can probably work around it with atomic counters.
This commit adds a few more metrics to the
PoolingAllocatorMetrics
type along the lines of accounting for more items as well as the unused slots in the pooling allocator. Notably the count of unused memory and table slots is exposed along with the number of bytes which are kept resident in these slots despite them not being in use. This involved a bit of plumbing to thread around the number of bytes that are actually kept resident to some more locations but is otherwise a pretty straightforward plumbing of accounting information we already had internally.