apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: cvs commit: apr/include apr_sms_trivial.h
Date Sun, 01 Jul 2001 18:52:24 GMT
[...]
>> We probably need to take a look at the list handling and see if
>> we can speed this up a bit.
> 
> Yeah, I tried trying to walk through the sentinel code last night and my
> brain just wasn't parsing the code.  It does need to be looked at with a
> fine-toothed comb.  I might get around to it later this afternoon.  It
> almost calls for pencil and paper to sketch out what the code is doing.

Please do. I wrote the code when I was very 'in focus'. I should have added
more comments, but didn't get around to it. I do know that the sentinels
do there job quite well with respect to eliminating checks. Let me know
what your findings are and if you see room for speed improvements.

> > Also, the values need tweaking (MAX_FREE, MIN_ALLOC, MIN_FREE). But
> > I think we should wait with that until we have a good testing
> > environment.
> 
> I wonder if you even need the MAX_FREE, MIN_ALLOC, and MIN_FREE stuff.
> Shouldn't we just leave those to the parent SMS?  That makes more sense
> to me.  I'm not really sold on the trivial SMS doing this sort of thing.
> (This sort of thing is WHY we have SMS in the first place, IMHO.)

No, the smss are layered. The parent sms could be the std_sms, which just
does malloc/free. In trivial you do almost exactly what pools do, but you
maintain a private free list. The MIN_FREE and MIN_ALLOC come from the
pools code. I did an apr_sms_trivial_create_ex() to be able to specify
these values at runtime (in case you don't like the defaults you get with
the apr_sms_trivial_create). See below for a note on the MAX_FREE define.

> I think with the testmem and Ian's testpool, I think we are close to 
> having a decent testing environment that is outside of the "real" 
> world.  The only thing I'm waiting on now is David's implementation of
> apr_pool_t as a SMS.  =)  

We need some decent debugging :)

> I was shocked that trivial was 102-103% of 
> the pool code (based on testmem results).  This is *without* 
> multi-threaded/unlocked allocation, which is where I believe that we're

There is a lock in the sms framework that is enabled by default. It is
acquired when apr_sms_reset is called. This lock has to be dynamically
created as the rest of the locks. I have a decent scheme in mind which
I will post Real Soon Now(tm).

If you disable the lock creation in apr_sms_create() [or, wait, we
moved it to apr_sms_post_init()] you should get better results. Also,
if you increase the MAX_FREE to a lot bigger you come closer to pools,
which doesn't free memory at all. With sms, you give it back to the
parent, which may hold on to it itself, or may give it back to the
system (which means that when a box has low load, the memory use
will go down).

> going to see a benefit from SMS long-term.  -- justin

Yes. Btw, I'm doing some last mods on an sms which I called threads_sms.
It is to be the parent sms of the smss that are in different threads.
It is based on trivial and has some nice properties when it comes to
locking. I'm hoping this will be a speed improvement in a threaded
environment. I will have to commit some groundwork for use later on
for that though.

Sander


Mime
View raw message