RE: [PATCH 2/9] lib/bitmap: implement bitmap_{empty,full} with bitmap_weight_eq()
From: David Laight <hidden>
Date: 2021-12-15 08:41:11
Also in:
kvm, linux-crypto, linux-mips, linux-perf-users, linux-riscv, linux-s390, linuxppc-dev, lkml
Possibly related (same subject, not in this thread)
- 2021-11-28 · Re: [PATCH 2/9] lib/bitmap: implement bitmap_{empty,full} with bitmap_weight_eq() · Yury Norov <yury.norov@gmail.com>
- 2021-11-28 · Re: [PATCH 2/9] lib/bitmap: implement bitmap_{empty,full} with bitmap_weight_eq() · Michał Mirosław <mirq-linux@rere.qmqm.pl>
- 2021-11-28 · [PATCH 2/9] lib/bitmap: implement bitmap_{empty,full} with bitmap_weight_eq() · Yury Norov <yury.norov@gmail.com>
From: Yury Norov
Sent: 14 December 2021 19:43
...
I think that for long bitmaps the most time consuming operation is moving data to L1, and for short bitmaps the difference between approaches is barely measurable. But hweght_long on each iteration can't be more effective than the current version. So, I'll drop this patch for v2 and keep things unchanged.
Actually do bitmap_full/empty() calls make any sense at all? The result is stale since bitmaps are designed to do locked operations. If you have a lock covering the bitmap then you should be using something that uses non-locked accesses. Rightly or wrongly that isn't the bitmap api. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)