Bug 2041637
| Summary: | RFE: add nanosecond display option to oslat | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Clark Williams <williams> | |
| Component: | realtime-tests | Assignee: | John Kacur <jkacur> | |
| Status: | CLOSED ERRATA | QA Contact: | Shizhao Chen <shichen> | |
| Severity: | unspecified | Docs Contact: | Sujata Kurup <skurup> | |
| Priority: | unspecified | |||
| Version: | 9.2 | CC: | bhu, crwood, jkacur, mstowell, peterx, shichen, skurup | |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged | |
| Target Release: | 9.2 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | realtime-tests-2.4-6.el9 | Doc Type: | Enhancement | |
| Doc Text: |
.The `-W` and `--bucket-width` options has been added to the `oslat` program to measure latency
With this enhancement, you can specify a latency range for a single bucket at nanoseconds accuracy. Widths that are not multiples of 1000 nanoseconds indicate nanosecond precision. By using the new options, `-W` or `--bucket-width`, you can modify the latency interval between buckets to measure latency within sub-microseconds delay time.
For example to set a latency bucket width of 100 nanoseconds for 32 buckets over a duration of 10 seconds to run on CPU range of 1-4 and omit zero bucket size, run the following command:
----
# oslat -b 32 -D 10s -W 100 -z -c 1-4
----
Note that before using the option, you must determine what level of precision is significant in relation to the error measurement.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2122374 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-09 07:30:49 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2122374 | |||
|
Description
Clark Williams
2022-01-17 22:40:26 UTC
Anyone knows what's the requirement of accuracy (e.g., 1ns, 10ns, 100ns)? It'll definitely be more challenging if we want to move the measurement to real nano-level, because then we'll need to rule out the oslat overhead, while that was not done in current measurements because currently the smallest bucket is 1us, and that's far bigger than the overhead itself. an 18 22:36:40 <peterx> jkacur: we need to measure the current overhead of oslat, and we need to know what we want to achieve, imho Jan 18 22:37:19 <jkacur> that all makes sense peterx Jan 18 22:37:37 <peterx> jkacur: e.g. the code path to fetch tsc, calculate diff, find and put bucket, etc. note: the overhead can differ a lot if e.g. whether we have cache hit or not on instruction and data accessing Jan 18 22:38:20 <peterx> jkacur: since we're talking about ns level, they'll all be in count. Hopefully 100ns is good enough, then we can simply add a few buckets, but still we'd better measure the overhead first to make sure it's far less than 100ns even if all cache miss Jan 18 22:39:09 <peterx> i haven't measured those so i cannot tell; it'll even differ on different hosts, so we'd better make sure it'll be mostly accurate on most Jan 18 22:41:15 <peterx> maybe it also does not make sense if we want to make it "really" 1ns level, because it seems extremely hard.. Jan 18 22:41:48 <peterx> (L1-L3 processor cache, TLB, iTLB, there're just too many uncertainties even running these bucket instructions..) Posted upstream patch: https://lore.kernel.org/linux-rt-users/20221209052254.2609767-1-swood@redhat.com/T/#u Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (realtime-tests bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2188 |