[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: SLAB for IDL stack allocation (ITS#2183)



This sounds like a great idea. I've briefly read this diff and have some
issues...

This should be a config file option, not a commandline switch. Moving the
option into back-bdb/config.c would also eliminate the need to modify slapd's
main.c/slap.h/mimic.c etc. This is the kind of feature that one would
typically turn on and leave on, command line switches are best used for
things that you only want to try once in a while (like debug options). (Also
my intent is to make config file options for other command-line switches
like -h, because again, this tends to be something you want set every time
slapd runs.) Adding the bdb_idl_slab_on variable into slapd itself violates
the abstraction layer, I think.

Also the patch to back-bdb/init.c looks like it has a bug. The chunk from
@@ -415,6 +429,20 @@ never assigns a value to "slab" but tries to reference
"slab->next" as well as free slab->buf and slab.

The bdb_idl_slab_on variable probably should be available both as a backend
option and as a database option. I would also use it as an int instead of a
boolean:
	idl_slab = 0, idl_slab = 16 <-- configure the max depth.
(Not so sure about this just yet, 16 is probably safe but you never know when
you might run across a legitimate sufficiently complex filter...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
> jongchoi@us.ibm.com
> Sent: Friday, November 15, 2002 7:17 AM
> To: openldap-its@OpenLDAP.org
> Subject: SLAB for IDL stack allocation (ITS#2183)
>
>
> Full_Name: Jong Hyuk Choi
> Version: All
> OS: RH 7.3
> URL: ftp://ftp.openldap.org/incoming/jongchoi-SLAB-021115.diff
> Submission from: (NULL) (198.81.209.17)
>
>
> Also through profiling, the source of performance discrepancy
> between IDL
> caching
> and candidate caching was identified as the memory allocation
> of IDL stack in
> search_candidates().
> Therefore, I also designed a simple slab allocator for the IDL stack
> allocation.
> Pleaes refer to ITS# 2182 for more detail.
> Comments are more than welcome.
> - Jong
>
> ---------------------------------------
> Jong Hyuk Choi, Ph. D
> Enterprise Linux Group
> IBM Thomas J. Watson Research Center
> jongchoi@us.ibm.com  jongchoi@OpenLDAP.org
>
>
>
>