Received-SPF: pass (google.com: domain of linux-kernel+bounces-103838-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240123005700.9302-1-dan@danm.net> <20240220230658.11069-1-dan@danm.net>
 <7efac6e0-32df-457e-9d21-4945c69328f8@leemhuis.info> <CAPhsuW5QYTjBvjAjf8SdcKmPGO20e5-p57n6af5FaXudSiOCmg@mail.gmail.com>
 <739634c3-3e21-44dd-abb1-356cf54e54fd@oracle.com> <d3cdebfe-17c0-4f61-9ad9-71d9de2339b2@oracle.com>
 <ecfce4d7-bcf7-c09a-7f01-5c7de88df107@huaweicloud.com> <ba26ac4f-160a-451e-a08b-27f577d8d2ba@oracle.com>
 <fa4beda8-986c-1112-f3f2-159f20674d47@huaweicloud.com> <e58155bf-71c1-48c4-94c7-b0d9ecbbef99@oracle.com>
In-Reply-To: <e58155bf-71c1-48c4-94c7-b0d9ecbbef99@oracle.com>
From: Song Liu <song@kernel.org>
Date: Thu, 14 Mar 2024 15:36:38 -0700
Message-ID: <CAPhsuW7V_n96PDp0wBe5pFNrrkZsbiTQZgZkY+FN7fpJYUmmaw@mail.gmail.com>
Subject: Re: [REGRESSION] 6.7.1: md: raid5 hang and unresponsive system;
 successfully bisected
To: junxiao.bi@oracle.com
Cc: Yu Kuai <yukuai1@huaweicloud.com>, 
	Linux regressions mailing list <regressions@lists.linux.dev>, gregkh@linuxfoundation.org, 
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, 
	stable@vger.kernel.org, Dan Moulding <dan@danm.net>, "yukuai (C)" <yukuai3@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2024 at 11:20=E2=80=AFAM <junxiao.bi@oracle.com> wrote:
>
[...]
> >>
> >> This patch eliminated the benefit of blk_plug, i think it will not be
> >> good for IO performance perspective?
> >
> > There is only one daemon thread, so IO should not be handled here as
> > much as possible. The IO should be handled by the thread that is
> > submitting the IO, and let daemon to hanldle the case that IO failed or
> > can't be submitted at that time.

raid5 can have multiple threads calling handle_stripe(). See raid5_do_work(=
).
Only chunk_aligned_read() can be handled in raid5_make_request.

>
> I am not sure how much it will impact regarding drop the blk_plug.
>
> Song, what's your take on this?

I think we need to evaluate the impact of (removing) blk_plug. We had
some performance regressions related to blk_plug a couple years ago.

Thanks,
Song