linux-kernel - Re: [PATCH] loop: inherit the ioprio in loop woker thread

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]

Date: Thu, 23 May 2024 10:15:25 +0800
From: yunlong xing <yunlongxing23@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Bart Van Assche <bvanassche@....org>, Yunlong Xing <yunlong.xing@...soc.com>, niuzhiguo84@...il.com, 
	Hao_hao.Wang@...soc.com, linux-block@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] loop: inherit the ioprio in loop woker thread

On Thu, May 23, 2024 at 2:13 AM Jens Axboe <axboe@...nel.dk> wrote:
>
> 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
>
Hi jens and bart，

Please let me explain the problem I'm having. There are many system service
processes in the Android system that access loop devices. The tasks of these
system services themselves have high IO priorities.

In the I/O stress tests such as filling disks, some disk devices like
emmc will cause
serious slowdowns. So now the disk speed is very slow, and there are still many
requests that need to be processed. I/O requests from system service taskes with
high I/O priority should be prioritized over filling disk task with
low I/O priority. The
purpose is that the I/O requests of the system service process are processed as
quickly as possible, without causing some stability problems due to being in the
ioschdule state for a long time. However, these system service taskes access the
loop device. If the priority cannot be passed, the I/O requests
submitted to the real
disk device through the loop kwoker cannot be prioritized over the I/O
requests of
the filling disk task. Then the complete process of system process accessing the
loop device will take a very long time.

So the purpose of what I do is to let the I/O priority of the task
accessing the loop
device pass to the kworker process that submit i/o to the real disk
device. Do you
think the io priority of the task accessing the loop device should not
be passed to
the kwoker task? Do you have any suggestions for my above-mentioned questions?