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.

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

Allow Disk IO meter to be above 100% #1374

Open
gooncreeper opened this issue Jan 13, 2024 · 8 comments · May be fixed by #1533
Open

Allow Disk IO meter to be above 100% #1374

gooncreeper opened this issue Jan 13, 2024 · 8 comments · May be fixed by #1533
Labels
enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent

Comments

@gooncreeper
Copy link

The latest htop version has capped the Disk IO meter at 100%, which is quite annoying as there is currently no per-disk utilization meter (#952) and doesn't seem like there will be one for a while. Allowing the Disk IO meter to be above 100% is useful if you have a disk that is always running at 100%, allowing you to see if other disks are running. This functionality was removed with 89b90c4

@BenBE BenBE added enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent labels Jan 13, 2024
@BenBE
Copy link
Member

BenBE commented Jan 13, 2024

@Explorer09 I think the patch should be supplemented to be scaled by the number of disks / multiple of 100% per disk.

@Explorer09
Copy link
Contributor

Explorer09 commented Jan 13, 2024

If there is one percentage for the disks, it should show the average percentages of all disks, not the "number of disks times 100%". Although the latter info might be useful, it isn't what average people think "percentage" for.

If you want the latter information, how about displaying as "x of y disks" in text display mode?

@gooncreeper
Copy link
Author

Averaging the total Disk IO would be less useful in most cases. For example, if you wanted to see how many disks are running at maximum, you would have to account for how many storage devices you have and multiply, but with a sum you could just look at the hundreds place. Additionally, having the Disk IO as a total would be more in line with the read and write statistics, which are totals of all the disks.

@Explorer09
Copy link
Contributor

Averaging the total Disk IO would be less useful in most cases. For example, if you wanted to see how many disks are running at maximum, you would have to account for how many storage devices you have and multiply, but with a sum you could just look at the hundreds place. Additionally, having the Disk IO as a total would be more in line with the read and write statistics, which are totals of all the disks.

I mean the percentage bar would show the average of all disk. But in the text display mode, add a "x out of y disks spinning" text.

@gooncreeper
Copy link
Author

But in the text display mode, add a "x out of y disks spinning" text.

Ah I see, your original phrasing made it seem like it would be something like "320% of 4 disks." (which is more confusing than just a percentage)

"x of y disk spinning" would solve the problem of seeing how many disks are running, though we would have to consider what spinning means for non-rotational devices. "x of y disks running" would probably be better (we just tally how many disks have been read/written to since the last refresh.) We could also offer both and having "spinning" apply only to rotational devices.

I mean the percentage bar would show the average of all disk.

Having a sum of all the disk percentages would still be better since the user wouldn't have to account for how many storage devices they have. If you had two disks but only use one, you probably wouldn't want the unused disk to half the percentage. I suppose a possible solution to that is only accounting mounted disks, though most systems might automatically mount disks you never use.

@rawhide-kobayashi
Copy link

What exactly was the rationale for changing this in the first place...?

Readings of >100% have their basis in the multi-core load average measure since the beginning of time itself.

With 30+ disks in my system "100%" disk IO is completely useless. It's never below 100% unless it's completely idle. The previous additive behavior was a useful at-a-glance indicator of total system disk busy time. It was literally perfect.

@Explorer09
Copy link
Contributor

@rawhide-kobayashi For multi-disk systems, the maximum value for the Disk IO meter should be (100% × number of disks), or the percentage should show the "normalized" one (i.e. divided by the number of the disks). So the value has been wrongly implemented in the first place.

I cannot make the decision on what the percentage should represent. My idea is the text should be "x of y disks busy" and not the percentage.

@gooncreeper
Copy link
Author

@rawhide-kobayashi For multi-disk systems, the maximum value for the Disk IO meter should be (100% × number of disks), or the percentage should show the "normalized" one (i.e. divided by the number of the disks).

Is there any good reason for normalizing the percentage?

@Explorer09 Explorer09 linked a pull request Sep 6, 2024 that will close this issue
Explorer09 added a commit to Explorer09/htop-1 that referenced this issue Sep 6, 2024
The utilization percentage of DiskIOMeter is an accumulated total of
all disks, and for multiple disks, utilization above 100% is possible.
The maximum utilization should be "100% * number of disks". Set the bar
and graph of the meter to draw with that maximum.

Thanks to Nathan Scott for providing the PCP portion of the patch.

Resolves htop-dev#1374.

Co-authored-by: Nathan Scott <[email protected]>
Signed-off-by: Kang-Che Sung <[email protected]>
Explorer09 added a commit to Explorer09/htop-1 that referenced this issue Sep 7, 2024
The utilization percentage of DiskIOMeter is an accumulated total of
all disks, and for multiple disks, utilization above 100% is possible.
The maximum utilization should be "100% * number of disks". Set the bar
and graph of the meter to draw with that maximum.

Thanks to Nathan Scott for providing the PCP portion of the patch.

Resolves htop-dev#1374.

Co-authored-by: Nathan Scott <[email protected]>
Signed-off-by: Kang-Che Sung <[email protected]>
Explorer09 added a commit to Explorer09/htop-1 that referenced this issue Sep 18, 2024
The utilization percentage of DiskIOMeter is an accumulated total of
all disks, and for multiple disks, utilization above 100% is possible.
The maximum utilization should be "100% * number of disks". Set the bar
and graph of the meter to draw with that maximum.

Thanks to Nathan Scott for providing the PCP portion of the patch.

Resolves htop-dev#1374.

Co-authored-by: Nathan Scott <[email protected]>
Signed-off-by: Kang-Che Sung <[email protected]>
Explorer09 added a commit to Explorer09/htop-1 that referenced this issue Sep 20, 2024
The utilization percentage of DiskIOMeter is an accumulated total of
all disks, and for multiple disks, utilization above 100% is possible.
The maximum utilization should be "100% * number of disks". Set the bar
and graph of the meter to draw with that maximum.

Thanks to Nathan Scott for providing the PCP portion of the patch.

Resolves htop-dev#1374.

Co-authored-by: Nathan Scott <[email protected]>
Signed-off-by: Kang-Che Sung <[email protected]>
Explorer09 added a commit to Explorer09/htop-1 that referenced this issue Oct 15, 2024
The utilization percentage of DiskIOMeter is an accumulated total of
all disks, and for multiple disks, utilization above 100% is possible.
The maximum utilization should be "100% * number of disks". Set the bar
and graph of the meter to draw with that maximum.

Thanks to Nathan Scott for providing the PCP portion of the patch.

Resolves htop-dev#1374.

Co-authored-by: Nathan Scott <[email protected]>
Signed-off-by: Kang-Che Sung <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Extension or improvement to existing feature needs-discussion 🤔 Changes need to be discussed and require consent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants