linux-kernel - Re: [PATCH v5] io_uring: Statistics of the true utilization of sq threads.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4c2de2e-b816-41eb-8646-8e57b7ed7913@kernel.dk>
Date: Fri, 22 Dec 2023 07:31:16 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Xiaobing Li <xiaobing.li@...sung.com>
Cc: asml.silence@...il.com, linux-kernel@...r.kernel.org,
 io-uring@...r.kernel.org, kun.dou@...sung.com, peiwei.li@...sung.com,
 joshi.k@...sung.com, kundan.kumar@...sung.com, wenwen.chen@...sung.com,
 ruyi.zhang@...sung.com
Subject: Re: [PATCH v5] io_uring: Statistics of the true utilization of sq
 threads.

On 12/22/23 1:35 AM, Xiaobing Li wrote:
> On 12/18/23 15:53, Jens Axboe wrote:
>> I think I'm convinced that the effectiveness of the chosen SQPOLL
>> settings being exposed is useful, I'm just not sure fdinfo is the right
>> place to do it. Is it going to be a problem that these are just
>> perpetual stats, with no way to reset them? This means there's no way to
>> monitor it for a period of time and get effectiveness for something
>> specific, it'll always just count from when the ring was created.
>>
>> We could of course have the act of reading the stat also reset it, but
>> maybe that'd be a bit odd?
>>
>> Alternatively, it could be exported differently, eg as a register opcode
>> perhaps.
>>
>> Open to suggestions...
> 
> I thought carefully about your proposed reset stat, and I think it can be 
> achieved by outputting "work_time" and "total_time".
> eg:
> Output at time t1:
> SqMask: 0x3
> SqHead: 1168417
> SqTail: 1168418
> SqWorkTime: t1_work
> SqTotalTime: t1_total
> 
> Output at time t2:
> SqMask: 0x3
> SqHead: 1168417
> SqTail: 1168418
> SqWorkTime: t2_work
> SqTotalTime: t2_total
> 
> Then we can manually calculate the utilization rate from t1 to t2:
> (t2_work - t1_work) / (t2_total - t1_total)
> 
> Not sure what you think, but if you think it doesn't work, I'll look into 
> other good ways to add the ability to reset.

Yep that would work, just leave the stats calculation to the tool
querying it. Which is really how it should be.

> In addition, on register opcode - generally it is used for resource like
> buffers, handles etc.. I am not sure how that can help here. If you have
> something in mind, could you please elaborate in more detail?

It's also a bit of a dumping ground for any kind of out-of-band
mechanism, so it would work fine for something like this too. But since
we already have fdinfo and with your idea of just logging work and total
time, then we should probably just stick with that.

-- 
Jens Axboe