On 08/08/2018 05:54 AM, Andy Shevchenko wrote: > On Tue, Aug 7, 2018 at 7:49 PM, Tony Battersby <tonyb@xxxxxxxxxxxxxxx> wrote: >> The "total number of blocks in pool" debug statistic currently does not >> take the boundary value into account, so it diverges from the "total >> number of blocks in use" statistic when a boundary is in effect. Add a >> calculation for the number of blocks per allocation that takes the >> boundary into account, and use it to replace the inaccurate calculation. > >> + retval->blks_per_alloc = >> + (allocation / boundary) * (boundary / size) + >> + (allocation % boundary) / size; > If boundary is guaranteed to be power of 2, this can avoid cost > divisions (though it's a slow path anyway). > At this point in the function, boundary is guaranteed to be either a power of 2 or equal to allocation, which might not be a power of 2. Not worth special-casing a slow path.
