Currently, the free block bitmap is roughly 4 times larger than it
needs to, wasting memory.
Let's assume maxsz = 128, minsz = 8 and n_max = 40.
Z_MPOOL_LVLS(128, 8) returns 3. The block size for level #0 is 128,
the block size for level #1 is 128/4 = 32, and the block size for
level #2 is 32/4 = 8. Hence levels 0, 1, and 2 for a total of 3 levels.
So far so good.
Now let's look at Z_MPOOL_LBIT_WORDS(). We get:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 0) = ((40 << 0) + 31) / 32 = 2
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 1) = ((40 << 2) + 31) / 32 = 5
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 2) = ((40 << 4) + 31) / 32 = 20
None of those are < 2 so Z_MPOOL_LBIT_WORDS() takes the results from
Z_MPOOL_LBIT_WORDS_UNCLAMPED().
Finally, let's look at _MPOOL_BITS_SIZE(. It sums all possible levels
with Z_MPOOL_LBIT_BYTES() which is:
#define Z_MPOOL_LBIT_BYTES(maxsz, minsz, l, n_max) \
(Z_MPOOL_LVLS((maxsz), (minsz)) >= (l) ? \
4 * Z_MPOOL_LBIT_WORDS((n_max), l) : 0)
Or given what we already have:
Z_MPOOL_LBIT_BYTES(128, 8, 0, 40) = (3 >= 0) ? 4 * 2 : 0 = 8
Z_MPOOL_LBIT_BYTES(128, 8, 1, 40) = (3 >= 1) ? 4 * 5 : 0 = 20
Z_MPOOL_LBIT_BYTES(128, 8, 2, 40) = (3 >= 2) ? 4 * 20 : 0 = 80
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * ??
Wait... we're missing this one:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 3) = ((40 << 6) + 31) / 32 = 80
then:
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * 80 : 0 = 320
Further levels yeld (3 >= 4), (3 >= 5), etc. so they're all false and
produce 0.
So this means that we're statically allocating 428 bytes to the bitmap
when clearly only the first 3 Z_MPOOL_LBIT_BYTES() results for the
corresponding 3 levels that we have should be summed e.g. only
108 bytes.
Here the code logic gets confused between level numbers and the number
levels, hence the extra allocation which happens to be exponential.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
744df1ef82