Re: ITS#2183 IDL stack slab

[jongchoi@us.ibm.com]

Thanks for letting the IDL stack slab cache design in.

One isssue is on the right sizing of the IDL stack.
If it is set to too small, searches having moderately complex
search filters may not benefit from the slab cache.
On the other hand, the memory overhead for large slabs may be quite big.
(With SRCH_STACK_SIZE of 16, each thread would consume 8MB for the slab.)

One approach I have been thinking of is to have two slab sizes :
one small and the other relatively big.
By having a TTL value to the big one and frees them after the TTL,
the amount of memory consumption can be maintained within a bound
while still providing preallocated memory to common searches having simple
search filters.
The size values and TTL values should also be configure by the cofiguration
file.

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979

----- Original Message -----
From: <hyc@highlandsun.com>
To: <openldap-its@OpenLDAP.org>
Sent: Tuesday, December 10, 2002 11:11 AM
Subject: ITS#2183 IDL stack slab


> Thinking about this some more; it can be greatly simplified. Instead of
> having a sequence of buckets of increasing length, just use a single
> fixed-size buffer per thread. This would also avoid the need for any
locking
> on the structures. (See the use of ldap_pvt_thread_pool_getkey/setkey in
> cache.c.) I can code this up pretty quickly for a test.
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com              ; http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>
>
>
>