On Wed, Apr 27, 2022 at 12:32:25PM -0700, Josh Hunt wrote: > On 4/27/22 02:57, Mikulas Patocka wrote: > > > [+ Mikulas and Ming] > > > > > > I see. Thank you for the response, Kuai, appreciate it. > > > > > > The conversation here https://urldefense.com/v3/__https://lkml.org/lkml/2020/3/24/1870__;!!GjvTz_vk!US3LozmCgynsWtz-1LkwhFPTXfY0XZNT7XKAw9GSNjZn0JkehqevMU7StsFKkjsS9b1hfGRsOCu0e1E$ hints at > > > potential improvements to io_ticks tracking. > > > > > > @Mikulas, Mike, please let us know if you have plans for more accurate > > > accounting or if there is some idea we can work on and submit a patch. > > > > I know that the accounting is not accurate, but more accurate accounting > > needed a shared atomic variable and it caused performance degradation. So, > > we don't plan to improve the accounting. > > Thanks this is all very helpful. > > If we know the accounting is not accurate then is there any reason to keep > it around? What value is it providing? Also, should we update tools that use > ioticks like iostat to report that disk utilization is deprecated and should > not be referred to going forward? man iostat ... %util Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100% for devices serving re‐ quests serially. But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits. ... As you saw, %util isn't accurate from the beginning. If you want a bit more accurate accounting before applying 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting"), it can be done easily by one simple bcc/bpftrace prog with extra cost. Thanks, Ming
