On Thu 26-10-23 20:51:22, Yury Norov wrote: > On Wed, Oct 25, 2023 at 10:18:00AM +0200, Rasmus Villemoes wrote: > > Yes, users will have to treat results from the find routines carefully > > if their bitmap may be concurrently modified. They do. Nobody wins if > > those users are forced to implement their own bitmap routines for their > > lockless algorithms. > > Again, I agree with this point, and I'm trying to address exactly this. > > I'm working on a series that introduces lockless find_bit functions > based on existing FIND_BIT() engine. It's not ready yet, but I hope > I'll submit it in the next merge window. > > https://github.com/norov/linux/commits/find_and_bit I agree that the find_and_{set|clear}() bit functions are useful and we'll be able to remove some boilerplate code with them. But also note that you will need to duplicate practically all of the bitmap API to provide similar "atomic" functionality - e.g. the sbitmap conversion you have in your branch has a bug that it drops the 'lock' memory ordering from the bitmap manipulation. So you need something like find_and_set_bit_lock() (which you already have) and find_and_set_bit_wrap_lock() (which you don't have yet). If you are to convert bitmap code in filesystems (some of which is lockless as well), you will need to add little and big endian variants of volatile bitmap functions. Finally there are users like lib/xarray.c which don't want to set/clear found bit (we just want to quickly find a good guess for a set bit in the bitmap and we then verify in another structure whether the guess was right or not). So we'll need the volatile variant of plain find_first_bit(), find_next_bit() as well. Also when we have variants of bitmap functions that are safe wrt parallel changes and those that are not, the function names should be probably indicating which are which. So as much as I agree your solution is theorically the cleanest, I personally don't think the cost in terms of code duplication and code churn is really worth it. > Now that we've got a test that presumably works faster if find_bit() > functions are all switched to be volatile, it would be great if we get > into details and understand: > - what find_bit function or functions gives that gain in performance; > - on what bitmap(s); > - is the reason in concurrent memory access (guess yes), and if so, > - can we refactor the code to use lockless find_and_bit() functions > mentioned above; > - if not, how else can we address this. Frankly, I don't think there's any substantial reason why the volatile or non-volatile code should be faster. The guys from compiler team looked at the x86 disassembly and said both variants should be the same speed based on instruction costs. What could be causing these small performance differences is that the resulting code is layed out slightly differently (and the volatile bitmap functions end up being somewhat larger) and that somehow interferes with instruction caching or CPU-internal out-of-order execution. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
