Received-SPF: pass (google.com: domain of linux-kernel+bounces-44081-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Xiaobing Li <xiaobing.li@samsung.com>
To: asml.silence@gmail.com
Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org,
	kun.dou@samsung.com, peiwei.li@samsung.com, joshi.k@samsung.com,
	kundan.kumar@samsung.com, wenwen.chen@samsung.com, ruyi.zhang@samsung.com,
	xiaobing.li@samsung.com
Subject: Re: Re: [PATCH v7] io_uring: Statistics of the true utilization of
 sq threads.
Date: Tue, 30 Jan 2024 13:47:42 +0800
Message-Id: <20240130054742.417610-1-xiaobing.li@samsung.com>
In-Reply-To: <3044a700-252c-4e87-a0cf-a1fec6e83f8f@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 105P
DLP-Filter: Pass
References: <3044a700-252c-4e87-a0cf-a1fec6e83f8f@gmail.com>
	<CGME20240130055554epcas5p2ad9d28f1e6c256db540ce985c4351461@epcas5p2.samsung.com>

On 1/29/24 15:01, Pavel Begunkov wrote:
>On 1/29/24 07:18, Xiaobing Li wrote:
>> On 1/18/24 19:34, Jens Axboe wrote:
>>>> diff --git a/io_uring/sqpoll.h b/io_uring/sqpoll.h
>>>> index 8df37e8c9149..c14c00240443 100644
>>>> --- a/io_uring/sqpoll.h
>>>> +++ b/io_uring/sqpoll.h
>>>> @@ -16,6 +16,7 @@ struct io_sq_data {
>>>>   	pid_t			task_pid;
>>>>   	pid_t			task_tgid;
>>>>   
>>>> +	long long			work_time;
>>>>   	unsigned long		state;
>>>>   	struct completion	exited;
>>>>   };
>>>
>>> Probably just make that an u64.
>>>
>>> As Pavel mentioned, I think we really need to consider if fdinfo is the
>>> appropriate API for this. It's fine if you're running stuff directly and
>>> you're just curious, but it's a very cumbersome API in general as you
>>> need to know the pid of the task holding the ring, the fd of the ring,
>>> and then you can get it as a textual description. If this is something
>>> that is deemed useful, would it not make more sense to make it
>>> programatically available in addition, or even exclusively?
>> 
>> Hi, Jens and Pavel
>> sorry for the late reply.
>> 
>> I've tried some other methods, but overall, I haven't found a more suitable
>> method than fdinfo.
>
>I wouldn't mind if it's fdinfo only for now, that can be changed later
>if needed. I'm more concerned that reading fdinfo and then parsing it
>is incompatible with the word performance, which you mentioned in the
>context of using 1 vs 2 syscalls to get the stats.
>
>That can be left to be resolved later, however. Let's just be clear
>in docs that stats could be 0, which means the feature is not
>working/disabled.
>
>Another question I raised in my reply (v6 thread), why it's using
>ktime_get(), which same as jiffies but more precise, instead of a
>task time?

Sorry, I forgot to reply to you.
I was thinking wrong. you are right,  we can use "getrusage" to statistics 
the work_time of sqpoll in the ring.

>
>
>> If you think it is troublesome to obtain the PID,  then I can provide
>
>I missed the context, where do we need to know PIDs?

Since obtaining the fdinfo content of sqpoll requires finding the corresponding 
PID first, I guess Jens thinks it is troublesome to manually obtain the PID of 
each sqpoll thread when there are many sqpoll threads.
Therefore, I want to write a script that can automatically output all sqpoll
 statistics.
 
--
Xiaobing Li