Skip to content
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.

Sign up for GitHub

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

Jump to bottom

vflush: Print reclaim statistics #323

Closed
wants to merge 3 commits into from
Closed

vflush: Print reclaim statistics #323

wants to merge 3 commits into from

Conversation

EchterAgo
Copy link

@EchterAgo EchterAgo commented Nov 9, 2023 •
edited
Loading

This shows how many reclaims have been processed in thousand increments and also how many reclaims are processed per second.

@EchterAgo EchterAgo marked this pull request as draft November 9, 2023 13:19
@EchterAgo
Copy link
Author

Some more testing revealed that last_stats_time_delta can be zero, maybe timer granularity? ChatGPT tells me the timer granularity of KeQueryTickCount is around 838 nanoseconds, doing 1000 reclaims should have taken longer than that, shouldn't it? I further optimized reclaim, maybe we are too fast now :D

@EchterAgo
Copy link
Author

I'm pretty sure ChatGPT is wrong about the granularity of KeQueryTickCount and yes, it does look like my last change sped up the loop a lot, now it is at ~64000 reclaims per second, where it was at hundreds and lower before, the time required grew exponentially with the number of nodes because we restarted the loop.

@EchterAgo
Copy link
Author

Yea, so the gethrtime value updates only every 15.625 milliseconds, if we do 1000 iterations in that time we get a divide by zero.

@EchterAgo
Copy link
Author

We should probably switch gethrtime to KeQueryPerformanceCounter

@EchterAgo
Copy link
Author

Ok, rebased on top of the gethrtime change and added a MAX to prevent divide by zero.

@EchterAgo EchterAgo marked this pull request as ready for review November 9, 2023 15:11
@EchterAgo
Copy link
Author

We can also skip this commit, I just used it to measure #328 before and after.

@EchterAgo EchterAgo force-pushed the add_reclaim_stats branch 4 times, most recently from 62e68d3 to 43bb86e Compare November 10, 2023 05:34
@EchterAgo EchterAgo mentioned this pull request Nov 10, 2023
Merged
@EchterAgo
spl-time: Use KeQueryPerformanceCounter instead of KeQueryTickCount
439c171 
`KeQueryTickCount` seems to only have a 15.625ms resolution unless the
interrupt timer frequency is increased, which should be avoided due to
power usage.

Instead, this switches the `zfs_lbolt`, `gethrtime` and
`random_get_bytes` to use `KeQueryPerformanceCounter`.

On my system this gives a 100ns resolution.

Signed-off-by: Axel Gembe <[email protected]>
@EchterAgo
spl-time: Add assertion to gethrtime and cache NANOSEC / freq division
c318c73 
One less division for each call.

Signed-off-by: Axel Gembe <[email protected]>
@EchterAgo
vflush: Print reclaim statistics
b5e0630 
This shows how many reclaims have been processed in thousand increments
and also how many reclaims are processed per second.

Signed-off-by: Axel Gembe <[email protected]>
@EchterAgo
Copy link
Author

Closing because merged as part of #328

@EchterAgo EchterAgo closed this Nov 10, 2023
@EchterAgo EchterAgo deleted the add_reclaim_stats branch November 10, 2023 05:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@EchterAgo