From: Frederic Weisbecker <frederic@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Mauro Carvalho Chehab <mchehab@s-opensource.com>,
"David S . Miller" <davem@davemloft.net>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Pavan Kondeti <pkondeti@codeaurora.org>,
Ingo Molnar <mingo@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 05/32] locking/lockdep: Prepare valid_state() to handle plain masks
Date: Thu, 21 Feb 2019 04:53:56 +0100 [thread overview]
Message-ID: <20190221035354.GA22364@lenoir> (raw)
In-Reply-To: <CAHk-=wh9q2o+oJtzuaZFPxXWrcKiO-bRBGBePfnLx6nPS+aiCA@mail.gmail.com>
On Wed, Feb 13, 2019 at 11:47:13AM -0800, Linus Torvalds wrote:
> On Wed, Feb 13, 2019 at 7:16 AM Frederic Weisbecker <frederic@kernel.org> wrote:
> > >
> > > If "vectors" only has the high hit set, you end up with "fs" having
> > > the value "64".
> > >
> > > And then "vectors >>= fs" is undefined and won't actually do anything
> > > at all on x86.
> >
> > Oh! ok didn't know that...
>
> So in general, shift counts >= width of the type (or negative) are undefined.
>
> They can sometimes happen to work (that's the "undefined" part ;), but
> it's not reliable or portable.
>
> It's why you occasionally see things like
>
> drivers/block/sx8.c:
> tmp = (blk_rq_pos(rq) >> 16) >> 16;
>
> to get the upper 32 bits of the value. It is written with that odd
> double shift, rather than being written as ">> 32". That way it works
> even if the sector type happens to be 32-bit (and the compiler will
> just end up turning it into a zero if it's an unsigned 32-bit type
> since it's compile-time obvious).
Ok, I see.
>
> > I see, perhaps I should use for_each_set_bit() that should take care about those
> > details?
>
> That would _work_, but don't do that. "for_each_set_bit()" works on
> bitmaps in memory, and is slow for a simple word case. In addition to
> being slow, it uses the Linux tradition of working on bitmaps that are
> comprised of "unsigned long". So it has byte order issues too.
>
> So for_each_set_bit() is useful when you have real arrays of bits and
> are using the "set_bit()" etc interfaces.
Yeah I suspected some overhead.
>
> When you're actually working on just a single variable, your "__ffs()"
> model works fine, you just need to be careful to _not_ do the "+1" and
> then use it for shifts.
>
> Also, it actually turns out that if you want to be really clever, you
> can play tricks if you don't care about the exact bit *number*.
>
> For example, this expression:
>
> v = a & (a-1);
>
> will remove the lowest bit set from 'a' very cheaply. So what you can
> do is something like this:
>
> void for_each_bit_in_mask(u64 mask)
> {
> while (mask) {
> u64 newmask = mask & (mask-1);
> u64 onebit = mask ^ newmask;
> mask = newmask;
> do_something_with(onebit);
> }
> }
>
> to do some operation on each bit set, and quite efficiently and
> without any undefined behavior or expensive shifts.
>
> But the above trick does require that you are happy to just see the
> bit *mask*, not the bit *number*. I'm not sure any of your cases match
> that.
Nice, I couldn't resist introducing such a headache in my set ;-) unfortunately
I indeed need the bit number itself most of the time.
So following your 1st advice, I should rather do something along the lines of:
nr = 0;
while (mask) {
fs = __ffs64(mask);
mask >>= fs;
mask >>= 1;
nr += fs + 1;
process_bit_nr(nr - 1);
}
And define a for_each_lock_usage_bit(usage_mask) on top of it.
Thanks a lot!
next prev parent reply other threads:[~2019-02-21 3:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 17:13 [PATCH 00/32] softirq: Per vector masking v2 Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 01/32] locking/lockdep: Use expanded masks on find_usage_*() functions Frederic Weisbecker
2019-02-12 17:35 ` Linus Torvalds
2019-02-12 17:13 ` [PATCH 02/32] locking/lockdep: Introduce struct lock_usage Frederic Weisbecker
2019-02-12 17:38 ` Linus Torvalds
2019-02-13 14:56 ` Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 03/32] locking/lockdep: Convert usage_mask to u64 Frederic Weisbecker
2019-02-12 17:40 ` Linus Torvalds
2019-02-13 14:51 ` Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 04/32] locking/lockdep: Test all incompatible scenario at once in check_irq_usage() Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 05/32] locking/lockdep: Prepare valid_state() to handle plain masks Frederic Weisbecker
2019-02-12 17:45 ` Linus Torvalds
2019-02-13 15:16 ` Frederic Weisbecker
2019-02-13 19:47 ` Linus Torvalds
2019-02-21 3:53 ` Frederic Weisbecker [this message]
2019-02-12 17:13 ` [PATCH 06/32] locking/lockdep: Prepare check_usage_*() " Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 07/32] locking/lockdep: Prepare state_verbose() to handle all softirqs Frederic Weisbecker
2019-02-12 17:13 ` [PATCH 08/32] locking/lockdep: Make mark_lock() fastpath to work with multiple usage at once Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 09/32] locking/lockdep: Save stack trace for each softirq vector involved Frederic Weisbecker
2019-02-12 17:47 ` Linus Torvalds
2019-02-13 15:18 ` Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 10/32] locking/lockdep: Make mark_lock() verbosity aware of vector Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 11/32] softirq: Macrofy softirq vectors Frederic Weisbecker
2019-02-27 9:54 ` Sebastian Andrzej Siewior
2019-02-27 23:08 ` Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 12/32] locking/lockdep: Define per vector softirq lock usage states Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 13/32] softirq: Pass softirq vector number to lockdep on vector execution Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 14/32] x86: Revert "x86/irq: Demote irq_cpustat_t::__softirq_pending to u16" Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 15/32] arch/softirq: Rename softirq_pending fields to softirq_data Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 16/32] softirq: Normalize softirq_pending naming scheme Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 17/32] softirq: Convert softirq_pending_*() to set/clear mask scheme Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 18/32] softirq: Introduce disabled softirq vectors bits Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 19/32] softirq: Rename _local_bh_enable() to local_bh_enable_no_softirq() Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 20/32] softirq: Move vectors bits to bottom_half.h Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 21/32] x86: Init softirq enabled field Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 22/32] softirq: Check enabled vectors before processing Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 23/32] softirq: Remove stale comment Frederic Weisbecker
2019-02-27 11:04 ` Sebastian Andrzej Siewior
2019-02-27 23:09 ` Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 24/32] softirq: Uninline !CONFIG_TRACE_IRQFLAGS __local_bh_disable_ip() Frederic Weisbecker
2019-02-27 11:14 ` Sebastian Andrzej Siewior
2019-02-27 23:14 ` Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 25/32] softirq: Prepare for mixing all/per-vector masking Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 26/32] softirq: Support per vector masking Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 27/32] locking/lockdep: Remove redundant softirqs on check Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 28/32] locking/lockdep: Update check_flags() according to new layout Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 29/32] locking/lockdep: Branch the new vec-finegrained softirq masking to lockdep Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 30/32] softirq: Allow to soft interrupt vector-specific masked contexts Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 31/32] locking: Introduce spin_[un]lock_bh_mask() Frederic Weisbecker
2019-02-12 17:14 ` [PATCH 32/32] net: Make softirq vector masking finegrained on release_sock() Frederic Weisbecker
2019-02-12 18:29 ` [PATCH 00/32] softirq: Per vector masking v2 David Miller
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=20190221035354.GA22364@lenoir \
--to=frederic@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@s-opensource.com \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.