-
Notifications
You must be signed in to change notification settings - Fork 324
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
Enable oppportunistic fd counting fast path #486
Enable oppportunistic fd counting fast path #486
Conversation
Existing slow path takes ~725ms of CPU time on my laptopto count 1 million open files. Compare this to just 0.25ms for the baseline, when no extra files are open by a Go program: ``` Open files reported: 7 Gathered metrics in 0.26ms Open files reported: 1000007 Gathered metrics in 724.50ms ``` Adding fastpath from Linux v6.2 makes it fast: ``` Open files reported: 6 Gathered metrics in 0.29ms Open files reported: 1000006 Gathered metrics in 0.31ms ``` This is before taking in account any lock contention effects in the kernel if you try to count files from multiple threads concurrently, which makes the slow path even slower, burning a lot more CPU in the process. See: * torvalds/linux@f1f1f2569901 Signed-off-by: Ivan Babrou <github@ivan.computer>
56693c8
to
0c0aed6
Compare
Tests are unhappy:
That's because they make
|
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.
Nice! LGTM, thanks!
No clear recommendation for the tests.. Might need to restructure this to fix it. |
For some behaviors there is no substitution for real `/proc`. One example is `stat()` for `/proc/<pid>/fd` returning the number of open files for `procfs`. The field has a different meaning on regular filesystems and we need to check for it in tests. Work around this by carrying the fact that `FS` is real in the `FS` struct itself, so that it can be checked where it matters. The realness is determined once per `FS` creation by doing `statfs()` and checking for the `PROC_SUPER_MAGIC` match in the returned fs type. Signed-off-by: Ivan Babrou <github@ivan.computer>
0b5c8ec
to
e1da5db
Compare
I added a commit with a possible solution. I'm not sure if it's a good one, but I can't think of anything better. Initially I hoped for a |
Existing slow path takes ~725ms of CPU time on my laptopto count 1 million open files. Compare this to just 0.25ms for the baseline, when no extra files are open by a Go program:
Adding fastpath from Linux v6.2 makes it fast:
This is before taking in account any lock contention effects in the kernel if you try to count files from multiple threads concurrently, which makes the slow path even slower, burning a lot more CPU in the process. See:
The code I used