[Date Prev][Date Next]
Re: (ITS#6437) sl_malloc issues
Hallvard B Furuseth wrote:
> email@example.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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/