[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d9795483-ef64-4fd6-be71-a3946ae8fb3e@kernel.dk>
Date: Wed, 22 May 2024 12:13:53 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Bart Van Assche <bvanassche@....org>,
Yunlong Xing <yunlong.xing@...soc.com>, yunlongxing23@...il.com,
niuzhiguo84@...il.com, Hao_hao.Wang@...soc.com
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] loop: inherit the ioprio in loop woker thread
On 5/22/24 12:12 PM, Bart Van Assche wrote:
> On 5/22/24 10:57, Jens Axboe wrote:
>> On 5/22/24 11:38 AM, Bart Van Assche wrote:
>>> On 5/22/24 00:48, Yunlong Xing wrote:
>>>> @@ -1913,6 +1921,10 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
>>>> set_active_memcg(old_memcg);
>>>> css_put(cmd_memcg_css);
>>>> }
>>>> +
>>>> + if (ori_ioprio != cmd_ioprio)
>>>> + set_task_ioprio(current, ori_ioprio);
>>>> +
>>>> failed:
>>>> /* complete non-aio request */
>>>> if (!use_aio || ret) {
>>>
>>> Does adding this call in the hot path have a measurable performance impact?
>>
>> It's loop, I would not be concerned with overhead. But it does look pretty
>> bogus to modify the task ioprio from here.
>
> Hi Jens,
>
> Maybe Yunlong uses that call to pass the I/O priority to the I/O submitter?
>
> I think that it is easy to pass the I/O priority to the kiocb submitted by
> lo_rw_aio() without calling set_task_ioprio().
Yeah that was my point, it's both the completely wrong way to do it, nor
is it a sane way to do it. If the current stack off that doesn't allow
priority to be passed, then that work would need to be done first.
--
Jens Axboe
Powered by blists - more mailing lists