Re: [PATCH 00/10] Fix confusion around MAX_ORDER

On Thu 2023-09-28 18:57:18, Paolo Bonzini wrote: > On 9/28/23 09:50, Mikulas Patocka wrote: > > > > Fix the bugs and then change the definition of MAX_ORDER to be > > > > inclusive: the range of orders user can ask from buddy allocator is > > > > 0..MAX_ORDER now. > > I think that exclusive

[PATCH v2 12/13] lib/bitmap: add compile-time test for __assign_bit() optimization

Commit dc34d5036692 ("lib: test_bitmap: add compile-time optimization/evaluations assertions") initially missed __assign_bit(), which led to that quite a time passed before I realized it doesn't get optimized at compilation time. Now that it does, add test for that just to make sure nothing will

Re: [PATCH 09/14] bitmap: extend bitmap_{get,set}_value8() to bitmap_{get,set}_bits()

From: Yury Norov Date: Mon, 9 Oct 2023 09:31:15 -0700 > + Alexander Potapenko > > On Mon, Oct 09, 2023 at 05:10:21PM +0200, Alexander Lobakin wrote: >> Sometimes there's need to get a 8/16/...-bit piece of a bitmap at a >> particular offset. Currently, there are only bitmap_{get,set}_value8()

Re: [PATCH 06/14] fs/ntfs3: rename bitmap_size() -> ntfs3_bitmap_size()

From: Yury Norov Date: Mon, 9 Oct 2023 09:50:15 -0700 > On Mon, Oct 09, 2023 at 05:10:18PM +0200, Alexander Lobakin wrote: >> bitmap_size() is a pretty generic name and one may want to use it for [...] >> @@ -961,7 +961,7 @@ static inline bool run_is_empty(struct runs_tree *run) >> } >> >>

Re: [PATCH 05/14] s390/cio: rename bitmap_size() -> idset_bitmap_size()

From: Yury Norov Date: Mon, 9 Oct 2023 09:35:20 -0700 > On Mon, Oct 09, 2023 at 05:10:17PM +0200, Alexander Lobakin wrote: >> bitmap_size() is a pretty generic name and one may want to use it for >> a generic bitmap API function. At the same time, its logic is not >> "generic", i.e. it's not

[PATCH v2 07/13] btrfs: rename bitmap_set_bits() -> btrfs_bitmap_set_bits()

bitmap_set_bits() does not start with the FS' prefix and may collide with a new generic helper one day. It operates with the FS-specific types, so there's no change those two could do the same thing. Just add the prefix to exclude such possible conflict. Reviewed-by: Przemek Kitszel Acked-by:

Re: [PATCH v2 00/13] ip_tunnel: convert __be16 tunnel flags to bitmaps

On Mon, Oct 16, 2023 at 06:52:34PM +0200, Alexander Lobakin wrote: > Based on top of "Implement MTE tag compression for swapped pages"[0] > from Alexander Potapenko as it uses its bitmap_{read,write}() functions > to not introduce another pair of similar ones. > > Derived from the PFCP support

[PATCH v2 09/13] bitmap: make bitmap_{get, set}_value8() use bitmap_{read, write}()

Now that we have generic bitmap_read() and bitmap_write(), which are inline and try to take care of non-bound-crossing and aligned cases to keep them optimized, collapse bitmap_{get,set}_value8() into simple wrappers around the former ones. bloat-o-meter shows no difference in vmlinux and -2 bytes

[PATCH v2 04/13] linkmode: convert linkmode_{test, set, clear, mod}_bit() to macros

Since commit b03fc1173c0c ("bitops: let optimize out non-atomic bitops on compile-time constants"), the non-atomic bitops are macros which can be expanded by the compilers into compile-time expressions, which will result in better optimized object code. Unfortunately, turned out that passing

Re: [PATCH 09/14] bitmap: extend bitmap_{get,set}_value8() to bitmap_{get,set}_bits()

On Wed, Oct 11, 2023 at 11:33:25AM +0200, Alexander Lobakin wrote: > From: Yury Norov > Date: Mon, 9 Oct 2023 09:31:15 -0700 > > > + Alexander Potapenko > > > > On Mon, Oct 09, 2023 at 05:10:21PM +0200, Alexander Lobakin wrote: > >> Sometimes there's need to get a 8/16/...-bit piece of a

[PATCH v2 08/13] bitmap: introduce generic optimized bitmap_size()

The number of times yet another open coded `BITS_TO_LONGS(nbits) * sizeof(long)` can be spotted is huge. Some generic helper is long overdue. Add one, bitmap_size(), but with one detail. BITS_TO_LONGS() uses DIV_ROUND_UP(). The latter works well when both divident and divisor are compile-time

[PATCH v2 03/13] bitops: let the compiler optimize {__,}assign_bit()

Since commit b03fc1173c0c ("bitops: let optimize out non-atomic bitops on compile-time constants"), the compilers are able to expand inline bitmap operations to compile-time initializers when possible. However, during the round of replacement if-__set-else-__clear with __assign_bit() as per Andy's

Re: [PATCH 03/14] bitops: let the compiler optimize __assign_bit()

From: Yury Norov Date: Mon, 9 Oct 2023 09:18:40 -0700 > On Mon, Oct 09, 2023 at 05:10:15PM +0200, Alexander Lobakin wrote: [...] >> -static __always_inline void __assign_bit(long nr, volatile unsigned long >> *addr, >> - bool value) >> -{ >> -if (value)

[PATCH v2 01/13] bitops: add missing prototype check

Commit 8238b4579866 ("wait_on_bit: add an acquire memory barrier") added a new bitop, test_bit_acquire(), with proper wrapping to try optimize it at compile-time, but missed the list of bitops used for checking their prototypes a bit below. The functions added have consistent prototypes, so that

[PATCH v2 00/13] ip_tunnel: convert __be16 tunnel flags to bitmaps

Based on top of "Implement MTE tag compression for swapped pages"[0] from Alexander Potapenko as it uses its bitmap_{read,write}() functions to not introduce another pair of similar ones. Derived from the PFCP support series[1] as this grew bigger (2 -> 13 commits) and involved more core bitmap

[PATCH v2 11/13] ip_tunnel: convert __be16 tunnel flags to bitmaps

Historically, tunnel flags like TUNNEL_CSUM or TUNNEL_ERSPAN_OPT have been defined as __be16. Now all of those 16 bits are occupied and there's no more free space for new flags. It can't be simply switched to a bigger container with no adjustments to the values, since it's an explicit Endian

Re: [PATCH 09/14] bitmap: extend bitmap_{get,set}_value8() to bitmap_{get,set}_bits()

On Wed, Oct 11, 2023 at 11:33:25AM +0200, Alexander Lobakin wrote: > From: Yury Norov > Date: Mon, 9 Oct 2023 09:31:15 -0700 > > > + Alexander Potapenko > > > > On Mon, Oct 09, 2023 at 05:10:21PM +0200, Alexander Lobakin wrote: > >> Sometimes there's need to get a 8/16/...-bit piece of a

[PATCH v2 13/13] lib/bitmap: add tests for IP tunnel flags conversion helpers

Now that there are helpers for converting IP tunnel flags between the old __be16 format and the bitmap format, make sure they work as expected by adding a couple of tests to the bitmap testing suite. The helpers are all inline, so no dependencies on the related CONFIG_* (or a standalone module)

[PATCH v2 06/13] fs/ntfs3: add prefix to bitmap_size() and use BITS_TO_U64()

bitmap_size() is a pretty generic name and one may want to use it for a generic bitmap API function. At the same time, its logic is NTFS-specific, as it aligns to the sizeof(u64), not the sizeof(long) (although it uses ideologically right ALIGN() instead of division). Add the prefix 'ntfs3_' used

[PATCH v2 10/13] ip_tunnel: use a separate struct to store tunnel params in the kernel

Unlike IPv6 tunnels which use purely-kernel __ip6_tnl_parm structure to store params inside the kernel, IPv4 tunnel code uses the same ip_tunnel_parm which is being used to talk with the userspace. This makes it difficult to alter or add any fields or use a different format for whatever data.

[PATCH v2 05/13] s390/cio: rename bitmap_size() -> idset_bitmap_size()

bitmap_size() is a pretty generic name and one may want to use it for a generic bitmap API function. At the same time, its logic is not "generic", i.e. it's not just `nbits -> size of bitmap in bytes` converter as it would be expected from its name. Add the prefix 'idset_' used throughout the file

Re: [PATCH v2 09/13] bitmap: make bitmap_{get,set}_value8() use bitmap_{read,write}()

On Mon, Oct 16, 2023 at 06:52:43PM +0200, Alexander Lobakin wrote: > Now that we have generic bitmap_read() and bitmap_write(), which are > inline and try to take care of non-bound-crossing and aligned cases > to keep them optimized, collapse bitmap_{get,set}_value8() into > simple wrappers around

[PATCH v2 02/13] bitops: make BYTES_TO_BITS() treewide-available

Avoid open-coding that simple expression each time by moving BYTES_TO_BITS() from the probes code to to export it to the rest of the kernel. Simplify the macro while at it. `BITS_PER_LONG / sizeof(long)` always equals to %BITS_PER_BYTE, regardless of the target architecture. Do the same for the