-
Notifications
You must be signed in to change notification settings - Fork 180
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
Create file-system-benchmarks.rs and update fs_latency_bench.sh accordingly #1213
Create file-system-benchmarks.rs and update fs_latency_bench.sh accordingly #1213
Conversation
…dingly Signed-off-by: Renan Magagnin <[email protected]>
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, I have put a few comments but I'm happy to see us building out this tool. Happy to chat!
#[derive(Parser, Debug)] | ||
struct CliArgs { |
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.
What's the purpose of this tool? We can add a description using rustdoc, and it'll also end up in the binary.
#[derive(Parser, Debug)] | |
struct CliArgs { | |
/// Benchmark tool for measuring the time of Linux file system operations. | |
#[derive(Parser, Debug)] | |
struct CliArgs { |
In particular, it's probably worth clarifying that this tool can only measure the time end-to-end rather than looking at FUSE operations.
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.
Added. I figured it's best not to include the mentioned clarification since it is possible to enable a breakdown of operation specific latencies with the --detailed
flag. Let me know if I misunderstood!
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 think the current desc is fine - I was trying to highlight that it specifically won't be able to measure a FUSE open
, since we cannot trigger them independently.
Signed-off-by: Renan Magagnin <[email protected]>
Signed-off-by: Renan Magagnin <[email protected]>
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.
Ship it!
Creation of a benchmarking binary for recreating and measuring the latencies of real-world usage patterns of Mountpoint. This version includes only a small file creation benchmark which measures the sequence of the file system operations: lookup, open, write (of one byte), and flush. The latency measurement captures the total duration and is averaged multiple iterations to ensure representativeness.
The benchmarking binary is used in the
fs_latency_bench.sh
script and the the new results are included in the final results of the script, ultimately being added to the benchmarking GitHub pages dashboard.Does this change impact existing behavior?
No.
Does this change need a changelog entry?
No.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).