Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 7 Sep 2022 12:20:09 -0600
From:   Keith Busch <kbusch@kernel.org>
To:     Jan Kara <jack@suse.cz>
Cc:     Yu Kuai <yukuai1@huaweicloud.com>, axboe@kernel.dk, osandov@fb.com,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        yukuai3@huawei.com, yi.zhang@huawei.com
Subject: Re: [PATCH] sbitmap: fix possible io hung due to lost wakeup
Message-ID: <Yxjg2Xsb7WExRv2w@kbusch-mbp.dhcp.thefacebook.com>
References: <20220803121504.212071-1-yukuai1@huaweicloud.com>
 <Yxe7V3yfBcADoYLE@kbusch-mbp.dhcp.thefacebook.com>
 <20220907102318.pdpzpmhah2m3ptbn@quack3>
 <YxinFEYRCU/QuQ5w@kbusch-mbp.dhcp.thefacebook.com>
 <20220907164150.tykjl3jsctjddcnq@quack3>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220907164150.tykjl3jsctjddcnq@quack3>
Precedence: bulk

On Wed, Sep 07, 2022 at 06:41:50PM +0200, Jan Kara wrote:
> On Wed 07-09-22 08:13:40, Keith Busch wrote:
> > 
> > I'm not sure about this part. We've already decremented, so the freed bit is
> > accounted for against the batch. Returning true here may double-count the freed
> > bit, right?
> 
> Yes, we may wake up waiters unnecessarily frequently. But that's a
> performance issue at worst and only if it happens frequently. So I don't
> think it matters in practice (famous last words ;).

Ok, let's go with that. Do you want to send the patch? I have a follow-up fix
for batched tagging that depends on this.