Hallvard B Furuseth wrote: > [email protected] 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/
