From: Yury Norov <yury.norov@gmail.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
netdev <netdev@vger.kernel.org>,
"open list:HFI1 DRIVER" <linux-rdma@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Mel Gorman <mgorman@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Barry Song <song.bao.hua@hisilicon.com>,
Heiko Carstens <hca@linux.ibm.com>,
Tony Luck <tony.luck@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Gal Pressman <gal@nvidia.com>, Tariq Toukan <tariqt@nvidia.com>
Subject: Re: [PATCH v2 1/5] bitops: Introduce find_next_andnot_bit()
Date: Fri, 19 Aug 2022 05:42:06 -0700 [thread overview]
Message-ID: <Yv+FHpyZ6gpIAXMw@yury-laptop> (raw)
In-Reply-To: <xhsmhk074a5eu.mognet@vschneid.remote.csb>
On Fri, Aug 19, 2022 at 11:34:01AM +0100, Valentin Schneider wrote:
> On 18/08/22 22:04, Andy Shevchenko wrote:
> > On Thu, Aug 18, 2022 at 8:18 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> >> On Thu, 18 Aug 2022 17:26:43 +0100
> >> Valentin Schneider <vschneid@redhat.com> wrote:
> >>
> >> > How about:
> >>
> >> >
> >> > find the next set bit in (*addr1 & ~*addr2)
> >>
> >> I understand the above better. But to convert that into English, we could
> >> say:
> >>
> >>
> >> Find the next bit in *addr1 excluding all the bits in *addr2.
> >>
> >> or
> >>
> >> Find the next bit in *addr1 that is not set in *addr2.
> >
> > With this explanation I'm wondering how different this is to
> > bitmap_bitremap(), with adjusting to using an inverted mask. If they
> > have something in common, perhaps make them in the same namespace with
> > similar naming convention?
> >
>
> I'm trying to wrap my head around the whole remap thing, IIUC we could have
> something like remap *addr1 to ~*addr2 and stop rather than continue with a
> wraparound, but that really feels like shoehorning.
Old and new maps create a simple forward-looking mapping, like this:
#0 #4
old: 0111 0 ...
| \\\|
New: 00 111 ...
So if you pass #0, it's wired to 0; but #1 will skip 1 bit and would be
wired to 2; and so on. There is some puzzling when wraparound comes in
play, but the general idea is like that.
I think there's nothing common with bitmap_and{,_not}.
Thanks,
Yury
next prev parent reply other threads:[~2022-08-19 12:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 17:58 [PATCH v2 0/5] sched, net: NUMA-aware CPU spreading interface Valentin Schneider
2022-08-17 17:58 ` [PATCH v2 1/5] bitops: Introduce find_next_andnot_bit() Valentin Schneider
2022-08-18 14:08 ` Steven Rostedt
2022-08-18 16:26 ` Valentin Schneider
2022-08-18 17:00 ` Steven Rostedt
2022-08-18 19:04 ` Andy Shevchenko
2022-08-19 10:34 ` Valentin Schneider
2022-08-19 12:42 ` Yury Norov [this message]
2022-08-17 17:58 ` [PATCH v2 2/5] cpumask: Introduce for_each_cpu_andnot() Valentin Schneider
2022-08-18 22:38 ` Yury Norov
2022-08-19 10:24 ` Valentin Schneider
2022-08-18 16:28 ` [PATCH v2 0/5] sched, net: NUMA-aware CPU spreading interface Jesse Brandeburg
2022-08-18 16:43 ` Valentin Schneider
2022-08-18 16:51 ` Valentin Schneider
2022-08-18 16:45 ` [PATCH v2 3/5] sched/topology: Introduce sched_numa_hop_mask() Valentin Schneider
2022-08-18 16:45 ` [PATCH v2 4/5] sched/topology: Introduce for_each_numa_hop_cpu() Valentin Schneider
2022-08-18 16:45 ` [PATCH v2 5/5] SHOWCASE: net/mlx5e: Leverage for_each_numa_hop_cpu() Valentin Schneider
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=Yv+FHpyZ6gpIAXMw@yury-laptop \
--to=yury.norov@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=davem@davemloft.net \
--cc=dietmar.eggemann@arm.com \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=hca@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=saeedm@nvidia.com \
--cc=song.bao.hua@hisilicon.com \
--cc=tariqt@nvidia.com \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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.