All of lore.kernel.org
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Guoqing Jiang <guoqing.jiang@linux.dev>,
	linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
	Song Liu <song@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Stephen Bates <sbates@raithlin.com>,
	Martin Oliveira <Martin.Oliveira@eideticom.com>,
	David Sloan <David.Sloan@eideticom.com>
Subject: Re: [PATCH v2 12/12] md/raid5: Pivot raid5_make_request()
Date: Wed, 27 Apr 2022 10:18:05 -0600	[thread overview]
Message-ID: <67153d42-93c0-def1-95d9-a09678cf343d@deltatee.com> (raw)
In-Reply-To: <61411981-6401-aaa7-9d3d-6a9ac1fec4f2@linux.dev>



On 2022-04-26 20:06, Guoqing Jiang wrote:
>>   +static int add_all_stripe_bios(struct stripe_head *sh, struct bio *bi,
>> +        sector_t first_logical_sector, sector_t last_sector,
>> +        int forwrite, int previous)
>> +{
>> +    int dd_idx;
>> +    int ret = 1;
>> +
>> +    spin_lock_irq(&sh->stripe_lock);
>> +
>> +    for (dd_idx = 0; dd_idx < sh->disks; dd_idx++) {
>> +        struct r5dev *dev = &sh->dev[dd_idx];
>> +
>> +        clear_bit(R5_BioReady, &dev->flags);
>> +
>> +        if (dd_idx == sh->pd_idx)
>> +            continue;
>> +
>> +        if (dev->sector < first_logical_sector ||
>> +            dev->sector >= last_sector)
>> +            continue;
>> +
>> +        if (stripe_bio_overlaps(sh, bi, dd_idx, forwrite)) {
>> +            set_bit(R5_Overlap, &dev->flags);
>> +            ret = 0;
>> +            continue;
>> +        }
>> +
>> +        set_bit(R5_BioReady, &dev->flags);
> 
> Is  it possible to just call __add_stripe_bio here? And change above
> "continue"
> to "return",

No. The reason it was done this way is because we either have to add the
bio to all the disks or none of them. Otherwise, if one fails and we
have to retry and we can't know which stripes were already added or not.

>> @@ -5869,6 +5911,10 @@ enum stripe_result {
>>   struct stripe_request_ctx {
>>       bool do_flush;
>>       struct stripe_head *batch_last;
>> +    sector_t disk_sector_done;
>> +    sector_t start_disk_sector;
>> +    bool first_wrap;
>> +    sector_t last_sector;
>>   };
> 
> Could you add some comments to above members if possible?

Yes, Christoph already asked for this and I've reworked this patch to
make it much clearer for v3.

>>   static enum stripe_result make_stripe_request(struct mddev *mddev,
>> @@ -5908,6 +5954,36 @@ static enum stripe_result
>> make_stripe_request(struct mddev *mddev,
>>         new_sector = raid5_compute_sector(conf, logical_sector, previous,
>>                         &dd_idx, NULL);
>> +
>> +    /*
>> +     * This is a tricky algorithm to figure out which stripe_heads that
>> +     * have already been visited and exit early if the stripe_head has
>> +     * already been done. (Seeing all disks are added to a stripe_head
>> +     * once in add_all_stripe_bios().
>> +     *
>> +     * To start with, the disk sector of the last stripe that has been
>> +     * completed is stored in ctx->disk_sector_done. If the
>> new_sector is
>> +     * less than this value, the stripe_head has already been done.
>> +     *
>> +     * There's one issue with this: if the request starts in the
>> middle of
>> +     * a chunk, all the stripe heads before the starting offset will be
>> +     * missed. To account for this, set the first_wrap boolean to true
>> +     * if new_sector is less than the starting sector. Clear the
>> +     * boolean once the start sector is hit for the second time.
>> +     * When first_wrap is set, ignore the disk_sector_done.
>> +     */
>> +    if (ctx->start_disk_sector == MaxSector) {
>> +        ctx->start_disk_sector = new_sector;
>> +    } else if (new_sector < ctx->start_disk_sector) {
>> +        ctx->first_wrap = true;
>> +    } else if (new_sector == ctx->start_disk_sector) {
>> +        ctx->first_wrap = false;
>> +        ctx->start_disk_sector = 0;
>> +        return STRIPE_SUCCESS;
>> +    } else if (!ctx->first_wrap && new_sector <=
>> ctx->disk_sector_done) {
>> +        return STRIPE_SUCCESS;
>> +    }
>> +
> 
> Hmm, with above tricky algorithm, I guess the point is that we can avoid
> to call below
> stripe_add_to_batch_list where has hash_lock contention. If so, maybe we
> can change
> stripe_can_batch for the purpose.

No, that's not the purpose. The purpose is to add the bio to the stripe
for every disk, so that we can avoid calling find_get_stripe() for every
single page and only call it once per stripe head.


>> diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
>> index 638d29863503..e73b58844f83 100644
>> --- a/drivers/md/raid5.h
>> +++ b/drivers/md/raid5.h
>> @@ -308,6 +308,7 @@ enum r5dev_flags {
>>       R5_Wantwrite,
>>       R5_Overlap,    /* There is a pending overlapping request
>>                * on this block */
>> +    R5_BioReady,    /* The current bio can be added to this disk */
> 
> This doesn't seem right to me, since the comment describes bio status
> while others
> are probably for r5dev.

I'm not sure I understand the objection. If you have a better option
please let me know.

I'm still working on this patch. Caught a couple more rare bugs that I'm
working to fix. The next version should also hopefully be clearer.

Thanks,

Logan



  reply	other threads:[~2022-04-27 16:51 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 19:54 [PATCH v2 00/12] Improve Raid5 Lock Contention Logan Gunthorpe
2022-04-20 19:54 ` [PATCH v2 01/12] md/raid5: Factor out ahead_of_reshape() function Logan Gunthorpe
2022-04-21  6:07   ` Christoph Hellwig
2022-04-21  9:17   ` Paul Menzel
2022-04-21 16:05     ` Logan Gunthorpe
2022-04-21 23:33       ` Wol
2022-04-27  1:28   ` Guoqing Jiang
2022-04-27 16:07     ` Logan Gunthorpe
2022-04-28  1:49       ` Guoqing Jiang
2022-04-28 15:44         ` Logan Gunthorpe
2022-04-29  0:24           ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 02/12] md/raid5: Refactor raid5_make_request loop Logan Gunthorpe
2022-04-21  6:08   ` Christoph Hellwig
2022-04-27  1:32   ` Guoqing Jiang
2022-04-27 16:08     ` Logan Gunthorpe
2022-04-28  1:16       ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 03/12] md/raid5: Move stripe_add_to_batch_list() call out of add_stripe_bio() Logan Gunthorpe
2022-04-27  1:33   ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 04/12] md/raid5: Move common stripe count increment code into __find_stripe() Logan Gunthorpe
2022-04-21  6:10   ` Christoph Hellwig
2022-04-27  1:33   ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 05/12] md/raid5: Factor out helper from raid5_make_request() loop Logan Gunthorpe
2022-04-21  6:14   ` Christoph Hellwig
2022-04-20 19:54 ` [PATCH v2 06/12] md/raid5: Drop the do_prepare flag in raid5_make_request() Logan Gunthorpe
2022-04-21  6:15   ` Christoph Hellwig
2022-04-27  2:11   ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 07/12] md/raid5: Move read_seqcount_begin() into make_stripe_request() Logan Gunthorpe
2022-04-21  6:15   ` Christoph Hellwig
2022-04-27  2:13   ` Guoqing Jiang
2022-04-20 19:54 ` [PATCH v2 08/12] md/raid5: Refactor for loop in raid5_make_request() into while loop Logan Gunthorpe
2022-04-21  6:16   ` Christoph Hellwig
2022-04-20 19:54 ` [PATCH v2 09/12] md/raid5: Keep a reference to last stripe_head for batch Logan Gunthorpe
2022-04-21  6:17   ` Christoph Hellwig
2022-04-27  1:36   ` Guoqing Jiang
2022-04-27 23:27     ` Logan Gunthorpe
2022-04-20 19:54 ` [PATCH v2 10/12] md/raid5: Refactor add_stripe_bio() Logan Gunthorpe
2022-04-21  6:18   ` Christoph Hellwig
2022-04-20 19:54 ` [PATCH v2 11/12] md/raid5: Check all disks in a stripe_head for reshape progress Logan Gunthorpe
2022-04-21  6:18   ` Christoph Hellwig
2022-04-27  1:53   ` Guoqing Jiang
2022-04-27 16:11     ` Logan Gunthorpe
2022-04-20 19:54 ` [PATCH v2 12/12] md/raid5: Pivot raid5_make_request() Logan Gunthorpe
2022-04-21  6:43   ` Christoph Hellwig
2022-04-21 15:54     ` Logan Gunthorpe
2022-04-27  2:06   ` Guoqing Jiang
2022-04-27 16:18     ` Logan Gunthorpe [this message]
2022-04-28  1:32       ` Guoqing Jiang
2022-04-21  8:45 ` [PATCH v2 00/12] Improve Raid5 Lock Contention Xiao Ni
2022-04-21 16:02   ` Logan Gunthorpe
2022-04-24  8:00     ` Guoqing Jiang
2022-04-25 15:39       ` Logan Gunthorpe
2022-04-25 16:12         ` Xiao Ni
2022-04-28 21:22           ` Logan Gunthorpe
2022-04-29  0:49             ` Guoqing Jiang
2022-04-29 16:01               ` Logan Gunthorpe
2022-04-30  1:44                 ` Guoqing Jiang
2022-04-24  7:53 ` Guoqing Jiang
2022-04-25 15:37   ` Logan Gunthorpe
2022-04-25 23:07 ` Song Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67153d42-93c0-def1-95d9-a09678cf343d@deltatee.com \
    --to=logang@deltatee.com \
    --cc=David.Sloan@eideticom.com \
    --cc=Martin.Oliveira@eideticom.com \
    --cc=guoqing.jiang@linux.dev \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=sbates@raithlin.com \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.