You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <dr...@jetnet.co.uk> on 2001/07/10 23:10:07 UTC
SMS as Pools Patch
OK, so I've had a couple of +1's for applying the patch, and 2.20 has been
released, so anyone object if I do it now?
david
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jul 12, 2001 at 11:20:59AM +0200, Sander Striker wrote:
> [...]
> >>> we _know_ that malloc and free are pretty efficient on
> >>> most operating systems. so why not rely on that
> >>> efficiency instead of trying to second-guess it and
> >>> round-up the malloc-block sizes?
> >>
> >> Because we most definitely get a significant speedup by
> >> allocating more mem than the user asks for, so we can serve
> >> the next request from our own block.
> >
> > okay... urr... so... again, you're second-guessing the
> > capabilities of the parent-mallocator (in this case,
> > malloc, via the default-sms.
> >
> > or, is the parent-mallocator another apr_[misnamed:)_trivial?
>
> It is another trivial. Oh, wait, you definitely need to take
> a look at apr/memory/unix/apr_sms_trivial.c. Justin added some
> comments so it should be a bit more clear what is happening at
> the moment than without the comments :)
ack. cvs update and comments to follow...
> > because if it's an apr_sms_trivial, then your speedup is
> > _actually_ achieved by avoiding problems in another part of,
> > or the usage of, apr_sms_trivial.
>
> It is probably the usage of. Also, problems can be avoided by
> using apr_sms_trivial_create_ex() which allows you to set
> min_free, min_alloc and max_free at runtime.
ah ha :)
> > > In case of the patch we get a stack where "trivial" is the
> > > child of another "trivial". We now have the child sms asking
> > > for mem for the parent, which adds the 4k bytes etc.
> > > We can circumvent this behaviour by doing the
> > > apr_sms_child_malloc and friends implementation.
> >
> > this really does sound to me like there is a problem
> > with stacking a trivial on top of a trivial, and that
> > the proposed solution is to make this a special case
> > to deal with what is effectively a broken situation.
>
> Yes, this could very well be. What stings me though is that
> stacking trivials is giving such a penalty. So basically,
> what I am trying to say is that the apr_sms_child_xxx
> functions make it possible to stack (2 of the same, or
> 2 smss that make assumptions about allocations) on top
> of eachother, without adding extra bytes for example.
>
... intuitively, i can only say that i'm not entirely
convinced.
which means that i feel that, given the current information
i know of, i can perceive a simpler and more structured
solution. but as usual, i am having difficulty sieving
it through my cross-wired brain into actual... like...
concepts, y'know. [i'll cut with the zen, now]
> >> [...]
> >>> surely there are better ways to do this that can be investigated
> >>> _before_ expanding the SMS API into a more complex system?
> >>
> >> Maybe... :)
> >> But that involves changes to the httpd codebase which is not an
> >> option with both pools and pools == sms should work. It will be
> >> numerous #ifdefs in the httpd code (at the location of every
> >> apr_pool_create) if we go down that road.
> >
> > .... how about a #define that makes apr_pool_create call a
> > new function that does what you need, especially if what
> > you need is the same in every place [exactly what, you haven't
> > explained, so i don't know :) ]
>
> We have that now. The first sms created is a std sms. All the others
> become trivial smss. Justin is doing some testing to see if we
> can do a trimix of std, trivial and tracking. In the long run it means
> that we are having to replace the apr_pool_create calls in httpd
> with the actual apr_sms_xxx_create call of the type of sms we need.
that is what i would expect to have to happen _anyway_ -
due to the other discussion-threads about considerations of doing one
pool per thread, blah blah _even_ if sms is not used.
same area, _probably_ the same problem :) :)
> > sorry to be so stick-in-the-mud, my friend, esp. on-list.
> > it's important to me that there are good reasons for things :)
>
> No prob :)
> Points well taken.
*silly grin*
lukes
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > > that Does A Better Job, well... tough! go use or write
> > > something else that isn't "trivial"'.
> >
> > Ah, the naming issue :)
> > I raised that a couple of times before commiting, and noone as
> > of yet has come up with a better name. I started out writing
apr_sms_...
trivial_buffered
trivial_buffer
trivial_pool
trivial_cache
pool
buffered
freecached
sentinel
?
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Thu, Jul 12, 2001 at 02:50:17AM -0700, Brian Pane wrote:
> >in other words, would it be better to have an extra parameter to
> >the malloc to indicate what the sms should do? advice to the
> >sms as to the _type_ of alllocation being performed?
> >
> Here's a possible taxonomy of allocation types:
>
> Type 1: Allocations that will not be returned to the SMS (and will
> get freed only when the SMS itself is destroyed)
[or reset to as-if-it-had-just-been-created]
> Type 2: Allocations that will be returned to the SMS during its
> lifetime
>
[... description of scenarios cut]
> Using this model, an SMS itself could figure out the type of
> each allocation request based on the number of bytes requested:
> small requests would get allocated out of the pool as in
> apr_sms_trivial, and large requests would get delegated to
> a root SMS that called malloc. (I guess an SMS that did this
> would be a hybrid tracking/trivial SMS?)
ooo! *goggle-eyed*.
y'know what i like about SMS? that it allows people to _have_
these discussions.
[the ultimate decision is, of course, well, we found out that pools
are The Best, and rip the whole lot :)]
...
what approach is taken by The Best memory allocators.
and do we wish to 'reinvent their wheels'?
do we have any _choice_ but to reinvent, or at least follow,
the inventions?
i've heard suggestions of creating one sms per thread, one
per processor, etc. and these are because existing memory
libraries already do this.
... food for thought.
luke
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
[...]
> Here's a possible taxonomy of allocation types:
>
> Type 1: Allocations that will not be returned to the SMS (and will
> get freed only when the SMS itself is destroyed)
>
> Type 2: Allocations that will be returned to the SMS during its
> lifetime
And this can be accomplished by choosing the type of sms to
use at create time.
> The first type includes most appliation data structures
> allocated from per-request pools in the httpd: small strings
> and structs. For these, the optimal implementation uses O(1)
> pointer arithmetic for allocation (like apr_sms_trivial or
> the original pool code), and deallocation is a no-op.
Yes.
> The second category includes bigger allocations: the messages
> in your RPC example, and subrequests in the httpd. For these,
> the deallocation can't be a no-op. Instead, the space being
> returned to the SMS should actually be made available for
> subsequent allocation requests. And the allocation/deallocation
> logic needs to be fast yet avoid too much fragmentation. To
> perform well in the general case, it basically needs to be a
> well-tuned malloc implementation.
>
> Using this model, an SMS itself could figure out the type of
> each allocation request based on the number of bytes requested:
> small requests would get allocated out of the pool as in
> apr_sms_trivial, and large requests would get delegated to
> a root SMS that called malloc. (I guess an SMS that did this
> would be a hybrid tracking/trivial SMS?)
I think a hybrid power of 2/tracking would do the trick very well.
This allows for fast reallocs which is what you need in RPC.
Sander
Re: SMS as Pools Patch
Posted by Brian Pane <bp...@pacbell.net>.
Luke Kenneth Casson Leighton wrote:
>On Wed, Jul 11, 2001 at 06:48:29PM +0200, Sander Striker wrote:
>
>>>>Ah, ok. The implementation of an sms calls apr_sms_child_malloc
>>>>instead of apr_sms_malloc when it wants memory from its parent.
>>>>
>>>.... okay... why?
>>>
>>Because there are situations where we would like to treat allocations
>>from a child sms different than from a user.
>>
>
>okay... such as?
>
>... and is this a slippery slope?
>
>first, we have user allocations. then we have child sms allocations.
>then there is ... grandchild sms allocations? then, maybe,
>faster sms allocations? then, maybe... sms allocations that
>are going to be a massive-repeat-loop on realloc, later [sander knows
>why this is: i'll explain it briefly, here. DCE/RPC function call
>transfers are split up into Protocol Data Unit sizes of a typically
>negotiated size of 0x1630 - 5680 - bytes. there is no limit on
>the *actual* amount of data that is transferred, and i'm not
>joking about that. NT has a hard-limit of 5megabytes but in
>practice, services tend to terminate with prejudice if you go
>above 1mb. you therefore receive potentially hundreds of 0x1630
>byte data blocks, and you have to strip out the first 16 bytes
>and chain the rest together...]
>
>in other words, would it be better to have an extra parameter to
>the malloc to indicate what the sms should do? advice to the
>sms as to the _type_ of alllocation being performed?
>
Here's a possible taxonomy of allocation types:
Type 1: Allocations that will not be returned to the SMS (and will
get freed only when the SMS itself is destroyed)
Type 2: Allocations that will be returned to the SMS during its
lifetime
The first type includes most appliation data structures
allocated from per-request pools in the httpd: small strings
and structs. For these, the optimal implementation uses O(1)
pointer arithmetic for allocation (like apr_sms_trivial or
the original pool code), and deallocation is a no-op.
The second category includes bigger allocations: the messages
in your RPC example, and subrequests in the httpd. For these,
the deallocation can't be a no-op. Instead, the space being
returned to the SMS should actually be made available for
subsequent allocation requests. And the allocation/deallocation
logic needs to be fast yet avoid too much fragmentation. To
perform well in the general case, it basically needs to be a
well-tuned malloc implementation.
Using this model, an SMS itself could figure out the type of
each allocation request based on the number of bytes requested:
small requests would get allocated out of the pool as in
apr_sms_trivial, and large requests would get delegated to
a root SMS that called malloc. (I guess an SMS that did this
would be a hybrid tracking/trivial SMS?)
--Brian
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
[...]
>>> we _know_ that malloc and free are pretty efficient on
>>> most operating systems. so why not rely on that
>>> efficiency instead of trying to second-guess it and
>>> round-up the malloc-block sizes?
>>
>> Because we most definitely get a significant speedup by
>> allocating more mem than the user asks for, so we can serve
>> the next request from our own block.
>
> okay... urr... so... again, you're second-guessing the
> capabilities of the parent-mallocator (in this case,
> malloc, via the default-sms.
>
> or, is the parent-mallocator another apr_[misnamed:)_trivial?
It is another trivial. Oh, wait, you definitely need to take
a look at apr/memory/unix/apr_sms_trivial.c. Justin added some
comments so it should be a bit more clear what is happening at
the moment than without the comments :)
> because if it's an apr_sms_trivial, then your speedup is
> _actually_ achieved by avoiding problems in another part of,
> or the usage of, apr_sms_trivial.
It is probably the usage of. Also, problems can be avoided by
using apr_sms_trivial_create_ex() which allows you to set
min_free, min_alloc and max_free at runtime.
> > In case of the patch we get a stack where "trivial" is the
> > child of another "trivial". We now have the child sms asking
> > for mem for the parent, which adds the 4k bytes etc.
> > We can circumvent this behaviour by doing the
> > apr_sms_child_malloc and friends implementation.
>
> this really does sound to me like there is a problem
> with stacking a trivial on top of a trivial, and that
> the proposed solution is to make this a special case
> to deal with what is effectively a broken situation.
Yes, this could very well be. What stings me though is that
stacking trivials is giving such a penalty. So basically,
what I am trying to say is that the apr_sms_child_xxx
functions make it possible to stack (2 of the same, or
2 smss that make assumptions about allocations) on top
of eachother, without adding extra bytes for example.
>> [...]
>>> surely there are better ways to do this that can be investigated
>>> _before_ expanding the SMS API into a more complex system?
>>
>> Maybe... :)
>> But that involves changes to the httpd codebase which is not an
>> option with both pools and pools == sms should work. It will be
>> numerous #ifdefs in the httpd code (at the location of every
>> apr_pool_create) if we go down that road.
>
> .... how about a #define that makes apr_pool_create call a
> new function that does what you need, especially if what
> you need is the same in every place [exactly what, you haven't
> explained, so i don't know :) ]
We have that now. The first sms created is a std sms. All the others
become trivial smss. Justin is doing some testing to see if we
can do a trimix of std, trivial and tracking. In the long run it means
that we are having to replace the apr_pool_create calls in httpd
with the actual apr_sms_xxx_create call of the type of sms we need.
> sorry to be so stick-in-the-mud, my friend, esp. on-list.
> it's important to me that there are good reasons for things :)
No prob :)
Points well taken.
Sander
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 06:48:29PM +0200, Sander Striker wrote:
> >> Ah, ok. The implementation of an sms calls apr_sms_child_malloc
> >> instead of apr_sms_malloc when it wants memory from its parent.
> >
> > .... okay... why?
>
> Because there are situations where we would like to treat allocations
> from a child sms different than from a user.
okay... such as?
... and is this a slippery slope?
first, we have user allocations. then we have child sms allocations.
then there is ... grandchild sms allocations? then, maybe,
faster sms allocations? then, maybe... sms allocations that
are going to be a massive-repeat-loop on realloc, later [sander knows
why this is: i'll explain it briefly, here. DCE/RPC function call
transfers are split up into Protocol Data Unit sizes of a typically
negotiated size of 0x1630 - 5680 - bytes. there is no limit on
the *actual* amount of data that is transferred, and i'm not
joking about that. NT has a hard-limit of 5megabytes but in
practice, services tend to terminate with prejudice if you go
above 1mb. you therefore receive potentially hundreds of 0x1630
byte data blocks, and you have to strip out the first 16 bytes
and chain the rest together...]
in other words, would it be better to have an extra parameter to
the malloc to indicate what the sms should do? advice to the
sms as to the _type_ of alllocation being performed?
> > how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> > and friends?
>
> By not exporting the apr_sms_child_xxx API. These functions are only
> available through the sms_private.h file.
okay, i buy that.
> > trivial to me says 'this is really simple. it works, it
> > probably stinks, we don't care: it proves the point,
> > it's proof-of-concept, you can get to grips with it
> > in under 5 minutes, and if you want more complex stuff
> > that Does A Better Job, well... tough! go use or write
> > something else that isn't "trivial"'.
>
> Ah, the naming issue :)
> I raised that a couple of times before commiting, and noone as
> of yet has come up with a better name. I started out writing
> an allocator that did fairly trivial stuff internally and so
> I called it trivial. Trivial can be described as pools morphed
> into sms now. For the naming issues go back a few weeks :)
:)
> > .... but leaving that issue aside, _why_ is the trivial_malloc
> > 'rounding up' the sizes to the nearest min_block size?
> >
> > that implies that you are second-guessing the parent
> > mallocator's ability to manage memory, and maybe
> > even screwing _up_ the parent mallocator's ability
> > to manage memory! in fact, that's exactly what's happening!
> >
> > we _know_ that malloc and free are pretty efficient on
> > most operating systems. so why not rely on that
> > efficiency instead of trying to second-guess it and
> > round-up the malloc-block sizes?
>
> Because we most definitely get a significant speedup by
> allocating more mem than the user asks for, so we can serve
> the next request from our own block.
okay... urr... so... again, you're second-guessing the
capabilities of the parent-mallocator (in this case,
malloc, via the default-sms.
or, is the parent-mallocator another apr_[misnamed:)_trivial?
because if it's an apr_sms_trivial, then your speedup is
_actually_ achieved by avoiding problems in another part of,
or the usage of, apr_sms_trivial.
> In case of the patch we get a stack where "trivial" is the
> child of another "trivial". We now have the child sms asking
> for mem for the parent, which adds the 4k bytes etc.
> We can circumvent this behaviour by doing the
> apr_sms_child_malloc and friends implementation.
this really does sound to me like there is a problem
with stacking a trivial on top of a trivial, and that
the proposed solution is to make this a special case
to deal with what is effectively a broken situation.
> [...]
> > surely there are better ways to do this that can be investigated
> > _before_ expanding the SMS API into a more complex system?
>
> Maybe... :)
> But that involves changes to the httpd codebase which is not an
> option with both pools and pools == sms should work. It will be
> numerous #ifdefs in the httpd code (at the location of every
> apr_pool_create) if we go down that road.
... how about a #define that makes apr_pool_create call a
new function that does what you need, especially if what
you need is the same in every place [exactly what, you haven't
explained, so i don't know :) ]
sorry to be so stick-in-the-mud, my friend, esp. on-list.
it's important to me that there are good reasons for things :)
all best,
luke
Re: SMS as Pools Patch
Posted by David Reid <dr...@jetnet.co.uk>.
Yeah, just commit it with the #ifdef's...
david
> On Thu, Jul 12, 2001 at 04:11:25PM +0200, Sander Striker wrote:
> > PS. I want to commit apr_threads_sms, but I don't know how to build
> > it conditionally. I could ofcourse just put #if APR_HAS_THREADS
> > #endif around all the code in apr_sms_threads.c, but that somehow
> > rubs me the wrong way.
>
> I fail to see the problem. That construct is used lots of places. =)
> -- justin
>
>
Re: SMS as Pools Patch
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jul 12, 2001 at 04:11:25PM +0200, Sander Striker wrote:
> PS. I want to commit apr_threads_sms, but I don't know how to build
> it conditionally. I could ofcourse just put #if APR_HAS_THREADS
> #endif around all the code in apr_sms_threads.c, but that somehow
> rubs me the wrong way.
I fail to see the problem. That construct is used lots of places. =)
-- justin
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
> If all the SMS's do this, i.e. it's done in the framework not in the
> specific SMS, then we will have a very nice locking strategy :)
>
> > > Basically I wanted to do locking on demand (so when 2 or more threads
> > > are using a sms it locks, when only 1 thread uses it, it doesn't
> (default)).
> > > Maybe we need to change one(1) line in the threaded mpm in httpd to
> > > allow it to work as intended, ~1 free list per thread.
>
> OK, I'll bite, what's the change that's required?
The apr_pool_create function that I assume is called in the mpm
(to be the parent for all the other pools in the threads created)
would need to become apr_sms_threads_create().
Ofcourse the other changes needed are in apr. In apr_thread_create
to be precise.
Sander
PS. I want to commit apr_threads_sms, but I don't know how to build
it conditionally. I could ofcourse just put #if APR_HAS_THREADS
#endif around all the code in apr_sms_threads.c, but that somehow
rubs me the wrong way.
Re: SMS as Pools Patch
Posted by David Reid <dr...@jetnet.co.uk>.
If all the SMS's do this, i.e. it's done in the framework not in the
specific SMS, then we will have a very nice locking strategy :)
> > Basically I wanted to do locking on demand (so when 2 or more threads
> > are using a sms it locks, when only 1 thread uses it, it doesn't
(default)).
> > Maybe we need to change one(1) line in the threaded mpm in httpd to
> > allow it to work as intended, ~1 free list per thread.
OK, I'll bite, what's the change that's required?
david
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> Basically I wanted to do locking on demand (so when 2 or more threads
> are using a sms it locks, when only 1 thread uses it, it doesn't (default)).
> Maybe we need to change one(1) line in the threaded mpm in httpd to
> allow it to work as intended, ~1 free list per thread.
fun, neh? :)
Changes to httpd WAS: RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
> > Part of the problem is that two of the people working on this don't
> > have commit access to httpd. David Reid does. I imagine that Sander
> > and I can do stuff and post it to the new-httpd list. If the
> > new-httpd list judges it a win, it'd go in. It isn't impossible for us
> > to get things in, but it just makes it a bit more difficult. -- justin
>
> Given that I'm trying (despite all the misleading subject lines) to follow
> this, if something needs to go into httpd then I'll commit it once I've
> looked at it. I actually think most of the issues are within APR and only
> once we've addressed some of those will we really be at the stage
> of making
> changes to httpd... Using the threads sms will be one place
> where it'll be
> worthwhile checking the effect, and if it's as good as we hope then making
> the change.
Well, this was not what I was getting at.
I meant that it is not, IMHO, advisable to do any changes to the
httpd codebase until we have a stable, proven, sms codebase.
In httpd everything should, for the time being, be transparent.
When, and most importantly, if, sms becomes the default in httpd we
can start ripping out apr_pool_create lines and replace them with
apr_sms_xxx_create calls (where xxx is the most appropiate sms instance
in that part of the application). For clarity: I'm not talking about
namespace now. It could very well be that apr_sms_xxx_create becomes
apr_pool_xxx_create in the future, but that's a different discussion.
The exception is ofcourse putting in some of these in exceptional locations:
#if POOLS_ARE_SMS
apr_sms_xxx_create(p, parent);
#else
apr_pool_create(p, parent);
#endif
But this is ofcourse no solution for all the apr_pool_create calls.
There are 39 apr_pool_create calls in httpd (this is excluding the
calls in apr and apr-util, but including all the modules, including
mod_example).
Sander
Re: SMS as Pools Patch
Posted by David Reid <dr...@jetnet.co.uk>.
> On Thu, Jul 12, 2001 at 11:12:15AM +0200, Luke Kenneth Casson Leighton
wrote:
> > one: pools in threads are messed up.
>
> Yes.
>
> > two: sms can't be developed effectively because no changes are
> > allowed to existing code. and some of the solutions being proposed
> > involve pools and threads.
> >
> > well, surely those two could be tested and developed at the
> > same time, yes?
>
> Part of the problem is that two of the people working on this don't
> have commit access to httpd. David Reid does. I imagine that Sander
> and I can do stuff and post it to the new-httpd list. If the
> new-httpd list judges it a win, it'd go in. It isn't impossible for us
> to get things in, but it just makes it a bit more difficult. -- justin
Given that I'm trying (despite all the misleading subject lines) to follow
this, if something needs to go into httpd then I'll commit it once I've
looked at it. I actually think most of the issues are within APR and only
once we've addressed some of those will we really be at the stage of making
changes to httpd... Using the threads sms will be one place where it'll be
worthwhile checking the effect, and if it's as good as we hope then making
the change.
david
Re: SMS as Pools Patch
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 12 Jul 2001, Justin Erenkrantz wrote:
> Part of the problem is that two of the people working on this don't
> have commit access to httpd. David Reid does. I imagine that Sander
> and I can do stuff and post it to the new-httpd list. If the
> new-httpd list judges it a win, it'd go in. It isn't impossible for us
> to get things in, but it just makes it a bit more difficult. -- justin
Just as an aside, I haven't had much time to keep up with the voluminous
traffic about SMS :-), but I'm more than happy to review patches to httpd
on that front if somebody needs a patch committed for them.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: SMS as Pools Patch
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Jul 12, 2001 at 11:12:15AM +0200, Luke Kenneth Casson Leighton wrote:
> one: pools in threads are messed up.
Yes.
> two: sms can't be developed effectively because no changes are
> allowed to existing code. and some of the solutions being proposed
> involve pools and threads.
>
> well, surely those two could be tested and developed at the
> same time, yes?
Part of the problem is that two of the people working on this don't
have commit access to httpd. David Reid does. I imagine that Sander
and I can do stuff and post it to the new-httpd list. If the
new-httpd list judges it a win, it'd go in. It isn't impossible for us
to get things in, but it just makes it a bit more difficult. -- justin
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
> > Realistically, though my thought for the long term is to have one root
> > trivial SMS (or similar SMS with a freelist) per thread
> > and a bunch of
> > tracking SMS (brain-dumb five-minute SMS that don't do much). I really
> > think this is where we ought to be headed. Does that need the
> > child_malloc path? Probably not.
>
> well...
>
> *thinks*.
>
> even _with_ the existing pools system, i've been watching the
> messages go back-and-forth about how pools and threads are messing
> everything up [general summary, i don't have the experience of
> actually _using_ this stuff :)].
>
> so, if that's the case, then there are two problems.
>
> one: pools in threads are messed up.
>
> two: sms can't be developed effectively because no changes are
> allowed to existing code. and some of the solutions being proposed
> involve pools and threads.
Well, the thread code is in apr so this can be easily touched without
changing the httpd codebase. This way we isolate the changes to just
be in apr (for now, optimization will require changes, but we need a
stable, proven, sms codebase first).
For ideas on resolving the problems take a look in the archive ;)
Basically I wanted to do locking on demand (so when 2 or more threads
are using a sms it locks, when only 1 thread uses it, it doesn't (default)).
Maybe we need to change one(1) line in the threaded mpm in httpd to
allow it to work as intended, ~1 free list per thread.
Sander
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 09:14:52AM -0700, Justin Erenkrantz wrote:
> On Wed, Jul 11, 2001 at 04:53:54PM +0200, Luke Kenneth Casson Leighton wrote:
> > how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> > and friends?
>
> It's not exported as a function? Only a SMS itself would see this
> function?
>
> > not being funny or anything, but what is a trivial mallocator
> > doing adding an extra 4096 bytes in the _first_ place?
>
> Well, part of it is inertia and an optimization. The current pool
> code adds an additional 4096 bytes to any allocation in order to
> make any allocation of <4096 bytes be done for free since we have
> already allocated it - we just tack it on to the block that we have
> just allocated. Dean Gaudet may have more explanation as to why we
> do this, but the current pool code definitely does this.
thanks justin.
> The completely trivial SMS is tracking. =) The names all suck
> horrendously, but no one has come up with good names for our SMS.
> Trivial SMS is the closest implementation of the current pool
> allocation system. Tracking is the one you should be able to grasp in
> <5 minutes.
okay... can we swap the names? [i'm serious!]
> Realistically, though my thought for the long term is to have one root
> trivial SMS (or similar SMS with a freelist) per thread
> and a bunch of
> tracking SMS (brain-dumb five-minute SMS that don't do much). I really
> think this is where we ought to be headed. Does that need the
> child_malloc path? Probably not.
well...
*thinks*.
even _with_ the existing pools system, i've been watching the
messages go back-and-forth about how pools and threads are messing
everything up [general summary, i don't have the experience of
actually _using_ this stuff :)].
so, if that's the case, then there are two problems.
one: pools in threads are messed up.
two: sms can't be developed effectively because no changes are
allowed to existing code. and some of the solutions being proposed
involve pools and threads.
well, surely those two could be tested and developed at the
same time, yes?
:)
0.02 Euros...
luke
Re: SMS as Pools Patch
Posted by dean gaudet <de...@arctic.org>.
On Wed, 11 Jul 2001, Justin Erenkrantz wrote:
> Well, part of it is inertia and an optimization. The current pool
> code adds an additional 4096 bytes to any allocation in order to
> make any allocation of <4096 bytes be done for free since we have
> already allocated it - we just tack it on to the block that we have
> just allocated. Dean Gaudet may have more explanation as to why we
> do this, but the current pool code definitely does this.
nope you've pretty much summed it up. it is a questionable optimisation
though.
> I'd like to see how it performs when MIN_FREE is set to 0. We'd suck
> at little allocation (actually not - consider that MIN_ALLOC is 4096,
> so if we allocate a bunch of small things in a row, this optimization
> is still present - just that if we allocate >4096 bytes, we don't get
> anything for free).
i think after i ironed out a few quirks i didn't bother playing with
MIN_FREE (which was there before i started playing with the allocator)...
even though it seemed somewhat damaging because of the odd sized blocks it
started to create on the freelist.
it's probably best to have MIN_FREE 0.
-dean
Re: SMS as Pools Patch
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jul 11, 2001 at 04:53:54PM +0200, Luke Kenneth Casson Leighton wrote:
> how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> and friends?
It's not exported as a function? Only a SMS itself would see this
function?
> not being funny or anything, but what is a trivial mallocator
> doing adding an extra 4096 bytes in the _first_ place?
Well, part of it is inertia and an optimization. The current pool
code adds an additional 4096 bytes to any allocation in order to
make any allocation of <4096 bytes be done for free since we have
already allocated it - we just tack it on to the block that we have
just allocated. Dean Gaudet may have more explanation as to why we
do this, but the current pool code definitely does this.
The completely trivial SMS is tracking. =) The names all suck
horrendously, but no one has come up with good names for our SMS.
Trivial SMS is the closest implementation of the current pool
allocation system. Tracking is the one you should be able to grasp in
<5 minutes.
I think with a true heap-based memory allocation system we really
don't need this. However, the SMS code needs to get checked in and
then we can start to play with other SMS strategies to determine what
are better options.
I'd like to see how it performs when MIN_FREE is set to 0. We'd suck
at little allocation (actually not - consider that MIN_ALLOC is 4096,
so if we allocate a bunch of small things in a row, this optimization
is still present - just that if we allocate >4096 bytes, we don't get
anything for free).
> that implies that you are second-guessing the parent
> mallocator's ability to manage memory, and maybe
> even screwing _up_ the parent mallocator's ability
> to manage memory! in fact, that's exactly what's happening!
The problem is that the trivial SMS are stacked on top of each other.
Since we add 4096 bytes to each malloc request, we're kind of screwed.
In the case of a child trivial SMS, we don't want the parent tacking on
more space than possible.
Realistically, though my thought for the long term is to have one root
trivial SMS (or similar SMS with a freelist) per thread and a bunch of
tracking SMS (brain-dumb five-minute SMS that don't do much). I really
think this is where we ought to be headed. Does that need the
child_malloc path? Probably not.
> surely there are better ways to do this that can be investigated
> _before_ expanding the SMS API into a more complex system?
We're open to ideas. =) The one criticism of SMS so far has been this
behavior with trivial SMS. Which, isn't really a fault of the SMS
design, just that fact that trivial isn't the greatest strategy.
-- justin
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
>> The exported API to userland will not change (see below).
>
> ack. okay. makes me happier.
>
>>> i know that there have been message flying back/forth.
>>> i don't understand them.
>>>
>>> please do me a favour: could you write up a clear explanation
>>> of exactly what the purpose of apr_sms_child_malloc is?
>>
>> Ah, ok. The implementation of an sms calls apr_sms_child_malloc
>> instead of apr_sms_malloc when it wants memory from its parent.
>
> .... okay... why?
Because there are situations where we would like to treat allocations
from a child sms different than from a user.
>> The same goes for calloc and free. These xxx_child_xxx functions
>> will _not_ be exported outside the SMS code space.
>
>> The xxx_child_xxx functions can be optionally present in an
>> sms to make a distinction between a user asking memory or a
>> child sms requesting memory.
>
> this is the bit that makes me nervous.
>
> it makes sms more complex to program to, to use, and to understand.
>
> how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> and friends?
By not exporting the apr_sms_child_xxx API. These functions are only
available through the sms_private.h file.
> > By default the framework will
> > use the malloc_fn, if a child_malloc_fn is present it will
> > use this. This allows us to handle child sms allocations
> > differently, hereby for example not letting the trivial
> > sms add the extra 4096 bytes on the alloc each time the
> > child requests 8192 bytes.
>
> .... urrr...
>
> not being funny or anything, but what is a trivial mallocator
> doing adding an extra 4096 bytes in the _first_ place?
>
> doesn't sound very trivial to me!
>
> trivial to me says 'this is really simple. it works, it
> probably stinks, we don't care: it proves the point,
> it's proof-of-concept, you can get to grips with it
> in under 5 minutes, and if you want more complex stuff
> that Does A Better Job, well... tough! go use or write
> something else that isn't "trivial"'.
Ah, the naming issue :)
I raised that a couple of times before commiting, and noone as
of yet has come up with a better name. I started out writing
an allocator that did fairly trivial stuff internally and so
I called it trivial. Trivial can be described as pools morphed
into sms now. For the naming issues go back a few weeks :)
> .... but leaving that issue aside, _why_ is the trivial_malloc
> 'rounding up' the sizes to the nearest min_block size?
>
> that implies that you are second-guessing the parent
> mallocator's ability to manage memory, and maybe
> even screwing _up_ the parent mallocator's ability
> to manage memory! in fact, that's exactly what's happening!
>
> we _know_ that malloc and free are pretty efficient on
> most operating systems. so why not rely on that
> efficiency instead of trying to second-guess it and
> round-up the malloc-block sizes?
Because we most definitely get a significant speedup by
allocating more mem than the user asks for, so we can serve
the next request from our own block. We always ask for
min_free bytes more (4096 bytes) than the user asks for,
at a minimum of min_alloc (8192 bytes).
In case of the patch we get a stack where "trivial" is the
child of another "trivial". We now have the child sms asking
for mem for the parent, which adds the 4k bytes etc.
We can circumvent this behaviour by doing the
apr_sms_child_malloc and friends implementation. The only thing
that changes is that the sms implementor has to type
apr_sms_child_malloc(parent, self, size) instead of
apr_sms_malloc(parent, size);
> btw, i'm quite happy to be told that i really don't
> get this, and to have things [im]patiently explained
> to me so i shut up :)
[...]
> surely there are better ways to do this that can be investigated
> _before_ expanding the SMS API into a more complex system?
Maybe... :)
But that involves changes to the httpd codebase which is not an
option with both pools and pools == sms should work. It will be
numerous #ifdefs in the httpd code (at the location of every
apr_pool_create) if we go down that road.
Sander
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Wed, Jul 11, 2001 at 04:32:54PM +0200, Sander Striker wrote:
> > > When one of us gets a chance, we can implement the child_malloc path in
> > > trivial. That should remove most of the current complaints about SMS.
> >
> > so, you want to add apr_sms_child_malloc etc. which makes
> > SMS a non-trivial API, which is one solution to the problem,
> > and the other solution is to write a better sms than
> > apr_sms_trivial.
> >
> > one solution makes the SMS api quite complex.
> >
> > the other keeps it simple.
>
> The exported API to userland will not change (see below).
ack. okay. makes me happier.
> > i know that there have been message flying back/forth.
> > i don't understand them.
> >
> > please do me a favour: could you write up a clear explanation
> > of exactly what the purpose of apr_sms_child_malloc is?
>
> Ah, ok. The implementation of an sms calls apr_sms_child_malloc
> instead of apr_sms_malloc when it wants memory from its parent.
... okay... why?
> The same goes for calloc and free. These xxx_child_xxx functions
> will _not_ be exported outside the SMS code space.
> The xxx_child_xxx functions can be optionally present in an
> sms to make a distinction between a user asking memory or a
> child sms requesting memory.
this is the bit that makes me nervous.
it makes sms more complex to program to, to use, and to understand.
how are you going to keep _users_ from _not_ using apr_sms_child_xxx
and friends?
> By default the framework will
> use the malloc_fn, if a child_malloc_fn is present it will
> use this. This allows us to handle child sms allocations
> differently, hereby for example not letting the trivial
> sms add the extra 4096 bytes on the alloc each time the
> child requests 8192 bytes.
... urrr...
not being funny or anything, but what is a trivial mallocator
doing adding an extra 4096 bytes in the _first_ place?
doesn't sound very trivial to me!
trivial to me says 'this is really simple. it works, it
probably stinks, we don't care: it proves the point,
it's proof-of-concept, you can get to grips with it
in under 5 minutes, and if you want more complex stuff
that Does A Better Job, well... tough! go use or write
something else that isn't "trivial"'.
... but leaving that issue aside, _why_ is the trivial_malloc
'rounding up' the sizes to the nearest min_block size?
that implies that you are second-guessing the parent
mallocator's ability to manage memory, and maybe
even screwing _up_ the parent mallocator's ability
to manage memory! in fact, that's exactly what's happening!
we _know_ that malloc and free are pretty efficient on
most operating systems. so why not rely on that
efficiency instead of trying to second-guess it and
round-up the malloc-block sizes?
btw, i'm quite happy to be told that i really don't
get this, and to have things [im]patiently explained
to me so i shut up :)
> > because it's very unclear [and i helped _design_ SMS, remember?]
> > and if it's unclear, i really don't think it's a good idea to
> > put it in, especially if there are other solutions.
> >
> > basically, apr_sms_child_malloc is giving me bad vibes - warning
> > alarm bells are ringing: that's the best way i can put it.
>
> Well, for now this is the best solution to solve the problems seen
> in apache _without_ modifying the apache codebase. It is a way to
> allow stacking of advanced memory systems in a more acceptable
> manner when it comes to performance/waste trade-off.
surely there are better ways to do this that can be investigated
_before_ expanding the SMS API into a more complex system?
all best,
luke
RE: SMS as Pools Patch
Posted by Sander Striker <st...@apache.org>.
> > When one of us gets a chance, we can implement the child_malloc path in
> > trivial. That should remove most of the current complaints about SMS.
>
> so, you want to add apr_sms_child_malloc etc. which makes
> SMS a non-trivial API, which is one solution to the problem,
> and the other solution is to write a better sms than
> apr_sms_trivial.
>
> one solution makes the SMS api quite complex.
>
> the other keeps it simple.
The exported API to userland will not change (see below).
> i know that there have been message flying back/forth.
> i don't understand them.
>
> please do me a favour: could you write up a clear explanation
> of exactly what the purpose of apr_sms_child_malloc is?
Ah, ok. The implementation of an sms calls apr_sms_child_malloc
instead of apr_sms_malloc when it wants memory from its parent.
The same goes for calloc and free. These xxx_child_xxx functions
will _not_ be exported outside the SMS code space.
The xxx_child_xxx functions can be optionally present in an
sms to make a distinction between a user asking memory or a
child sms requesting memory. By default the framework will
use the malloc_fn, if a child_malloc_fn is present it will
use this. This allows us to handle child sms allocations
differently, hereby for example not letting the trivial
sms add the extra 4096 bytes on the alloc each time the
child requests 8192 bytes.
> because it's very unclear [and i helped _design_ SMS, remember?]
> and if it's unclear, i really don't think it's a good idea to
> put it in, especially if there are other solutions.
>
> basically, apr_sms_child_malloc is giving me bad vibes - warning
> alarm bells are ringing: that's the best way i can put it.
Well, for now this is the best solution to solve the problems seen
in apache _without_ modifying the apache codebase. It is a way to
allow stacking of advanced memory systems in a more acceptable
manner when it comes to performance/waste trade-off.
> luke
Sander
Re: SMS as Pools Patch
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Tue, Jul 10, 2001 at 03:03:23PM -0700, Justin Erenkrantz wrote:
> On Tue, Jul 10, 2001 at 10:10:07PM +0100, David Reid wrote:
> > OK, so I've had a couple of +1's for applying the patch, and 2.20 has been
> > released, so anyone object if I do it now?
>
> I'd say go for it.
>
> When one of us gets a chance, we can implement the child_malloc path in
> trivial. That should remove most of the current complaints about SMS.
so, you want to add apr_sms_child_malloc etc. which makes
SMS a non-trivial API, which is one solution to the problem,
and the other solution is to write a better sms than
apr_sms_trivial.
one solution makes the SMS api quite complex.
the other keeps it simple.
i know that there have been message flying back/forth.
i don't understand them.
please do me a favour: could you write up a clear explanation
of exactly what the purpose of apr_sms_child_malloc is?
because it's very unclear [and i helped _design_ SMS, remember?]
and if it's unclear, i really don't think it's a good idea to
put it in, especially if there are other solutions.
basically, apr_sms_child_malloc is giving me bad vibes - warning
alarm bells are ringing: that's the best way i can put it.
luke
Re: SMS as Pools Patch
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Jul 10, 2001 at 10:10:07PM +0100, David Reid wrote:
> OK, so I've had a couple of +1's for applying the patch, and 2.20 has been
> released, so anyone object if I do it now?
I'd say go for it.
When one of us gets a chance, we can implement the child_malloc path in
trivial. That should remove most of the current complaints about SMS.
Once we are there, we can then take a step back and figure out what we
want to do.
I may commit the sms_replay_t that I submitted earlier that works with
Ian's testpool program. Thoughts on that? -- justin