linux-kernel - Re: 10x I/O await times in 6.12

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: <CAGis_TU1V2_L227SP9Ut1gSTNx9-AT9nbwgJH6azzH8==35hBQ@mail.gmail.com>
Date: Mon, 21 Apr 2025 20:10:05 +0100
From: Matt Fleming <mfleming@...udflare.com>
To: Keith Busch <kbusch@...nel.org>
Cc: Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org, 
	linux-kernel@...r.kernel.org, kernel-team <kernel-team@...udflare.com>
Subject: Re: 10x I/O await times in 6.12

On Mon, 21 Apr 2025 at 19:53, Keith Busch <kbusch@...nel.org> wrote:
>
> Not sure. I'm also guessing cond_resched is the reason for your
> observation, so that might be worth confirming is happening in whatever
> IO paths you're workload is taking in case there's some other
> explanation.

Yep, you're spot on. We're hitting cond_resched() from various code
paths (xfs_buf_delwri_submit_buffers(), swap_writepage(),
rmap_walk_file(), etc, etc).

sudo bpftrace -e 'k:psi_task_switch {        $prev = (struct
task_struct *)arg0;        if ($prev->plug != 0) {
                if ($prev->plug->cur_ktime) {
                        @[kstack(3)] = count();
                }
        }
}'
Attaching 1 probe...
^C

@[
    psi_task_switch+5
    __schedule+2081
    __cond_resched+51
]: 3044

> fs-writeback happens to work around it by unplugging if it knows
> cond_resched is going to schedule. The decision to unplug here wasn't
> necessarily because of the plug's ktime, but it gets the job done:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/fs-writeback.c?h=v6.15-rc3#n1984
>
> Doesn't really scale well to copy this for every caller of
> cond_resched(), though. An io specific helper implementation of
> cond_resched might help.
>
> Or if we don't want cond_resched to unplug (though I feel like you would
> normally want that), I think we could invalidate the ktime when
> scheduling to get the stats to read the current ktime after the process
> is scheduled back in.

Thanks. Makes sense to me. I'll try this out and report back.

> ---
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6978,6 +6978,9 @@ static void __sched notrace preempt_schedule_common(void)
>                  * between schedule and now.
>                  */
>         } while (need_resched());
> +
> +       if (current->flags & PF_BLOCK_TS)
> +               blk_plug_invalidate_ts(current);
>  }
>
>  #ifdef CONFIG_PREEMPTION
> --