From: Jan Kara <jack@suse.cz>
To: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Yu Kuai <yukuai1@huaweicloud.com>, Jan Kara <jack@suse.cz>,
Ming Lei <ming.lei@redhat.com>, "yukuai (C)" <yukuai3@huawei.com>,
axboe@kernel.dk, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, kbusch@kernel.org,
Laibin Qiu <qiulaibin@huawei.com>
Subject: Re: [PATCH RESEND v2 5/5] sbitmap: correct wake_batch recalculation to avoid potential IO hung
Date: Mon, 16 Jan 2023 10:54:44 +0100 [thread overview]
Message-ID: <20230116095444.z77f6lvvxeys7zdi@quack3> (raw)
In-Reply-To: <16d02f7b-8e0e-097c-63bc-ef83eb9cb05b@huaweicloud.com>
On Mon 16-01-23 10:15:08, Kemeng Shi wrote:
>
>
> on 1/3/2023 10:12 AM, Kemeng Shi wrote:
> > Friendly ping...
> >
> > on 12/26/2022 4:57 PM, Yu Kuai wrote:
> >> 在 2022/12/26 15:50, Yu Kuai 写道:
> >>
> >>>> why using
> >>>> wake batch of 4 is safe for cards with say 32 tags in case active_users is
> >>>> currently 32. Because I don't see why that is correct either.
> >>>>
> >>
> >> I see, you guys are worried that during the period that some hctx
> >> complete all it's not idle yet. It's right waiter might wait for
> >> other hctx to become idle to be awaken in this case. However, I'm
> >> not sure which way is better.
> >>
> >> Ming, do you have any idea?
> >>
> >> Thanks,
> >> Kuai
> >>
> >
> Hi Jan. The magic batch 4 seems just for performance initially while
> lacks of full consideration. And there is no better solution provided
> in futher. Do you have any suggestion that I can do to make more
> progress.
Yeah, since there was not any good reasoning behind the magic batch of size
4, feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
to this patch.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2023-01-16 9:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 14:33 [PATCH RESEND v2 0/5] A few bugfix and cleanup patches for sbitmap Kemeng Shi
2022-12-22 14:33 ` [PATCH RESEND v2 1/5] sbitmap: remove unnecessary calculation of alloc_hint in __sbitmap_get_shallow Kemeng Shi
2022-12-22 11:01 ` Jan Kara
2022-12-22 14:33 ` [PATCH RESEND v2 2/5] sbitmap: remove redundant check in __sbitmap_queue_get_batch Kemeng Shi
2022-12-22 11:23 ` Jan Kara
2022-12-22 11:49 ` Kemeng Shi
2022-12-22 12:16 ` Jan Kara
2022-12-22 14:33 ` [PATCH RESEND v2 3/5] sbitmap: rewrite sbitmap_find_bit_in_index to reduce repeat code Kemeng Shi
2022-12-22 12:23 ` Jan Kara
2022-12-22 14:33 ` [PATCH RESEND v2 4/5] sbitmap: add sbitmap_find_bit to remove repeat code in __sbitmap_get/__sbitmap_get_shallow Kemeng Shi
2022-12-22 12:42 ` Jan Kara
2022-12-22 14:33 ` [PATCH RESEND v2 5/5] sbitmap: correct wake_batch recalculation to avoid potential IO hung Kemeng Shi
2022-12-22 13:41 ` Jan Kara
2022-12-26 7:50 ` Yu Kuai
2022-12-26 8:57 ` Yu Kuai
2023-01-03 2:12 ` Kemeng Shi
2023-01-16 2:15 ` Kemeng Shi
2023-01-16 9:54 ` Jan Kara [this message]
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=20230116095444.z77f6lvvxeys7zdi@quack3 \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=qiulaibin@huawei.com \
--cc=shikemeng@huaweicloud.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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.