From: Omar Sandoval <osandov@osandov.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH 1/2] sbitmap: ammortize cost of clearing bits
Date: Fri, 30 Nov 2018 13:41:36 -0800 [thread overview]
Message-ID: <20181130214136.GB11220@vader> (raw)
In-Reply-To: <f830e923-2307-5e0d-102d-be681a3b1601@kernel.dk>
On Fri, Nov 30, 2018 at 01:10:47PM -0700, Jens Axboe wrote:
> On 11/30/18 1:03 PM, Omar Sandoval wrote:
> > On Fri, Nov 30, 2018 at 09:01:17AM -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.
> >>
> >> 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().
> >>
> >> 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.
> >>
> >> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >> ---
> >> include/linux/sbitmap.h | 31 +++++++++++++---
> >> lib/sbitmap.c | 80 +++++++++++++++++++++++++++++++++++++----
> >> 2 files changed, 100 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/include/linux/sbitmap.h b/include/linux/sbitmap.h
> >> index 804a50983ec5..07f117ee19dc 100644
> >> --- a/include/linux/sbitmap.h
> >> +++ b/include/linux/sbitmap.h
> >> @@ -30,14 +30,24 @@ struct seq_file;
> >> */
> >> struct sbitmap_word {
> >> /**
> >> - * @word: The bitmap word itself.
> >> + * @depth: Number of bits being used in @word/@cleared
> >> */
> >> - unsigned long word;
> >> + unsigned long depth;
> >>
> >> /**
> >> - * @depth: Number of bits being used in @word.
> >> + * @word: word holding free bits
> >> */
> >> - unsigned long depth;
> >> + unsigned long word ____cacheline_aligned_in_smp;
> >
> > Still splitting up word and depth in separate cachelines?
>
> Yeah, I mentioned that in one of the other postings, there's still a
> definite win to doing that.
>
> > Okay, I couldn't find any holes in this one :)
>
> Good to hear that :-)
>
> >> -unsigned int sbitmap_weight(const struct sbitmap *sb)
> >> +static unsigned int __sbitmap_weight(const struct sbitmap *sb, bool set)
> >> {
> >> unsigned int i, weight = 0;
> >>
> >> for (i = 0; i < sb->map_nr; i++) {
> >> const struct sbitmap_word *word = &sb->map[i];
> >>
> >> - weight += bitmap_weight(&word->word, word->depth);
> >> + if (set)
> >> + weight += bitmap_weight(&word->word, word->depth);
> >
> > Should probably do
> > weight -= bitmap_weight(&word->cleared, word->depth);
> >
> > too, right?
>
> We only use these for the debugfs stuff, how about I just make it static
> instead?
Yeah, with that,
Reviewed-by: Omar Sandoval <osandov@fb.com>
next prev parent reply other threads:[~2018-11-30 21:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 16:01 [PATCHSET v4] sbitmap optimizations Jens Axboe
2018-11-30 16:01 ` [PATCH 1/2] sbitmap: ammortize cost of clearing bits Jens Axboe
2018-11-30 20:03 ` Omar Sandoval
2018-11-30 20:10 ` Jens Axboe
2018-11-30 21:41 ` Omar Sandoval [this message]
2018-11-30 16:01 ` [PATCH 2/2] sbitmap: optimize wakeup check Jens Axboe
2018-11-30 21:37 ` Omar Sandoval
-- strict thread matches above, loose matches on Subject: below --
2018-11-30 2:09 [PATCHSET v3] sbitmap optimizations Jens Axboe
2018-11-30 2:09 ` [PATCH 1/2] sbitmap: ammortize cost of clearing bits Jens Axboe
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=20181130214136.GB11220@vader \
--to=osandov@osandov.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox