[Date Prev][Date Next]
RE: ITS#2183 IDL stack slab
The code now in CVS makes the size configurable. Having a second setting for
a big slab might be good. I'm not sure I'd worry about expiring a big slab;
if it's ever going to be used again you might as well keep it allocated.
Assuming you tune the "small" setting to cover 90-some percent of your
queries, you may get by with a single big slab that is grown/realloc'd as
The default size of 16 is probably overkill, someone whose system is tight on
VM will need to set it lower...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: Jonghyuk Choi [mailto:firstname.lastname@example.org]
> 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
> - Jong
> Jong Hyuk Choi
> IBM Thomas J. Watson Research Center - Enterprise Linux Group
> P. O. Box 218, Yorktown Heights, NY 10598
> email: email@example.com
> (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
> ----- Original Message -----
> From: <firstname.lastname@example.org>
> 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
> > 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