Re: [PATCH v6 00/12] lib/find_bit: fast path for small bitmaps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 1, 2021 at 12:29 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:

On Thu, Apr 1, 2021 at 11:16 AM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:

On Thu, Apr 1, 2021 at 3:36 AM Yury Norov <yury.norov@xxxxxxxxx> wrote:

Bitmap operations are much simpler and faster in case of small bitmaps
which fit into a single word. In linux/bitmap.c we have a machinery that
allows compiler to replace actual function call with a few instructions
if bitmaps passed into the function are small and their size is known at
compile time.

find_*_bit() API lacks this functionality; but users will benefit from it
a lot. One important example is cpumask subsystem when
NR_CPUS <= BITS_PER_LONG.

Cool, thanks!

I guess it's assumed to go via Andrew's tree.

But after that since you are about to be a maintainer of this, I think
it would make sense to send PRs directly to Linus. I would recommend
creating an official tree (followed by an update in the MAINTAINERS)
and connecting it to Linux next (usually done by email to Stephen).

It depends on how often we expect to see updates to this. I have not
followed the changes as closely as I should have, but I can also
merge them through the asm-generic tree for this time so Andrew
has to carry fewer patches for this.

I normally don't have a lot of material for asm-generic either, half
the time there are no pull requests at all for a given release. I would
expect future changes to the bitmap implementation to only need
an occasional bugfix, which could go through either the asm-generic
tree or through mm and doesn't need another separate pull request.

If it turns out to be a tree that needs regular updates every time,
then having a top level repository in linux-next would be appropriate.

Agree. asm-generic may serve for this. My worries are solely about how
much burden we add on Andrew's shoulders.

-- 
With Best Regards,
Andy Shevchenko



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux