Hallvard B Furuseth wrote:

hyc@symas.com writes:

...

Nobody uses the pool code. I would suggest you profile it against the stack code before spending any time fixing it.

The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply the allocated amounts by 17. The stack version stays happy. I also tried RE23 and rev 1.48 in case of code rot. (Should have tried OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a sl_malloc fallback to ch_malloc instead of returning NULL didn't help.

Anyway, I tried this because I assume the pool version is intended to reduce the number of sl_malloc fallbacks to ch_malloc, but that almost never happens in 'make test' with the current SLAP_SLAB_SIZE. Which made that aspect hard to test.

Also the pool version does a number of ch_mallocs for administration and ch_frees them at reset. If the idea is to reduce ch_mallocs, it should keep these blocks around. (Or allocate them with the slab.) Except the 'slab_object's It only needs cleanup if the slab size changes, which slapd never seems to do.

This stuff was originally written to grow the slab as needed, but it was also being very braindead and would have kept a lot of excess memory lying around so I dropped that. So right, currently the slab size doesn't change.