Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH 2/3] sbitmap: ammortize cost of clearing bits
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <20181209055146.GA17190@roeck-us.net>
Date:   Sat, 8 Dec 2018 23:19:59 -0700
Cc:     linux-block@vger.kernel.org, osandov@osandov.com,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AAE999B-AB08-46D0-9DF8-9CED32E6141B@kernel.dk>
References: <20181130011234.32674-1-axboe@kernel.dk> <20181130011234.32674-3-axboe@kernel.dk> <20181209055146.GA17190@roeck-us.net>
To:     Guenter Roeck <linux@roeck-us.net>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Dec 8, 2018, at 10:51 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>=20
> Hi,
>=20
>> On Thu, Nov 29, 2018 at 06:12:33PM -0700, Jens Axboe wrote:
>> sbitmap maintains a set of words that we use to set and clear bits, with
>> each bit representing a tag for blk-mq. Even though we spread the bits
>> out and maintain a hint cache, one particular bit allocated will end up
>> being cleared in the exact same spot.
>>=20
>> This introduces batched clearing of bits. Instead of clearing a given
>> bit, the same bit is set in a cleared/free mask instead. If we fail
>> allocating a bit from a given word, then we check the free mask, and
>> batch move those cleared bits at that time. This trades 64 atomic bitops
>> for 2 cmpxchg().
>>=20
>> In a threaded poll test case, half the overhead of getting and clearing
>> tags is removed with this change. On another poll test case with a
>> single thread, performance is unchanged.
>>=20
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>=20
> This patch results in irq lock inversion warnings when trying to boot
> from usb drives. This was observed with qemu boots of aarch64, x86, and
> x86_64 images.

This one is a false positive, was already reported last week. Just need to a=
dd some lockdep annotation for it.=20