On Mon, 12 Feb 2024 16:01:38 +0200
Andy Shevchenko [off-list ref] wrote:

On Mon, Feb 12, 2024 at 02:37:53PM +0100, Herve Codina wrote:

quoted

On Mon, 12 Feb 2024 14:27:16 +0200
Andy Shevchenko [off-list ref] wrote:  

quoted

On Mon, Feb 12, 2024 at 08:56:31AM +0100, Herve Codina wrote:  

quoted

Currently the bitmap_onto() is available only for CONFIG_NUMA=y case,
while some users may benefit out of it and being independent to NUMA
code.

Make it available to users by moving out of ifdeffery and exporting for
modules.    

Wondering if you are trying to have something like
https://lore.kernel.org/lkml/20230926052007.3917389-1-andriy.shevchenko@linux.intel.com/ (local)  

Yes, it looks like.
Can you confirm that your bitmap_scatter() do the same operations as the
existing bitmap_onto() ?  

I have test cases to be 100% sure, but on the first glance, yes it does with
the adjustment to the atomicity of the operations (which I do not understand
why be atomic in the original bitmap_onto() implementation).

This actually gives a question if we should use your approach or mine.
At least the help of bitmap_onto() is kinda hard to understand.

Agree, the bitmap_onto() code is simpler to understand than its help.

I introduced bitmap_off() to be the "reverse" bitmap_onto() operations
and I preferred to avoid duplicating function that do the same things.

On my side, I initially didn't use the bitmap_*() functions and did the the
bits manipulation by hand.
During the review, it was suggested to use the bitmap_*() family and I followed
this suggestion. I did tests to be sure that bitmap_onto() and bitmap_off() did
exactly the same things as my previous code did.

quoted

If so, your bitmap_gather() will match my bitmap_off() (patch 4 in this
series).  

Yes.

Regards,
Hervé