You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Pane <bp...@pacbell.net> on 2001/08/25 20:02:48 UTC
Re: Review of possible replacement for pools
Justin Erenkrantz wrote:
>On Sat, Aug 25, 2001 at 08:05:03PM +0200, Sander Striker wrote:
>
>>Adding an option to apr_pool_create_ex to indicate that the pool is
>>going to be shared across threads would be an option I can certainly
>>live with. OTOH, this will introduce an extra if(lock) pair in the
>>apr_palloc and apr_pcalloc calls. I'll send in a patch later on.
>>
>
>If you aren't shared, you have an extra NULL-check. I think that is
>acceptable. If you are shared, we make sure we can't get trounced.
>
I agree, as long as the NULL-check doesn't measurably impact
performance. One of the key success factors for the original pool
code is the very short code path in the common case where it doesn't
need to allocate new blocks. Adding another branch to this code
path might or might not slow it down measurably--but we can find
out through benchmarking.
--Brian
Re: Review of possible replacement for pools
Posted by Brian Pane <bp...@pacbell.net>.
Bill Stoddard wrote:
>Why are we spending time trying to optimize pools when we haven't eliminated the
>malloc/frees in the bucket brigade calls? The miniscule performance improvements
>you -might- get optimizing pools will be completely obscured by the overhead of the
>malloc/frees.
>
I'm skeptical of this conclusion. Ian's and Justin's experimental results
show measurable improvements in CPU usage and throughput from modified pool
code. Fixing the malloc/free overhead in brigades will be a big win on
systems with a slow malloc, but the benchmark numbers so far indicate that
it need not be in the critical path for fixing the pool scalability.
IMHO, fixing the mutex contention in pools sooner, rather than later, is
also
a good idea in general because it removes an architectural bottleneck
that can
hide the effects of performance tuning in other areas.
--Brian
RE: Review of possible replacement for pools
Posted by Sander Striker <st...@apache.org>.
> > > Why are we spending time trying to optimize pools when we haven't
> > > eliminated the
> > > malloc/frees in the bucket brigade calls? The miniscule
> > > performance improvements
> > > you -might- get optimizing pools will be completely obscured by
> > > the overhead of the
> > > malloc/frees.
> > >
> > > Bill
> >
> > Because it also eliminates the locking in the threaded mpm.
> > And, I wanted to see if I could squeeze some extra performance
> > out of it and make it a bit more readable. I don't know if
> > I succeeded in the latter. Or the performance for that matter :)
> >
> > Btw, why couldn't we use pools in brigades again?
> >
>
> Brigades need to be maintained across multiple requests to handle
> http pipelined
> responses, so allocating them out of a request pool clearly will
> not work. You could
> allocate the brigades out of a connection pool, but connections
> can remain active for
> 100's of requests so you could leak a lot of storage for the
> duration of the connection.
Wait, couldn't you create a new pool for each brigade, allocate
the brigade out of that pool, associate that pool with the brigade?
Then, when the brigade needs to go, just destroy that pool.
What am I missing?
> Bill
Re: Review of possible replacement for pools
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > Why are we spending time trying to optimize pools when we haven't
> > eliminated the
> > malloc/frees in the bucket brigade calls? The miniscule
> > performance improvements
> > you -might- get optimizing pools will be completely obscured by
> > the overhead of the
> > malloc/frees.
> >
> > Bill
>
> Because it also eliminates the locking in the threaded mpm.
> And, I wanted to see if I could squeeze some extra performance
> out of it and make it a bit more readable. I don't know if
> I succeeded in the latter. Or the performance for that matter :)
>
> Btw, why couldn't we use pools in brigades again?
>
Brigades need to be maintained across multiple requests to handle http pipelined
responses, so allocating them out of a request pool clearly will not work. You could
allocate the brigades out of a connection pool, but connections can remain active for
100's of requests so you could leak a lot of storage for the duration of the connection.
Bill
Re: pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Saturday, August 25, 2001 1:40 PM
> > I have a problem with the original question though. I don't understand why
> > anybody is trying to state that if people want to improve the pools code, they
> > shouldn't, because we use malloc in one place in the code. People are
> > free to work on whatever they want.
>
> I am not being philosophical. Sure, people can spend their time doing whatever they want.
> I assume open source developers like to see others benefit from their labor. If the goal
> is to improve the performance of the http server, (remember this was posted to dev@httpd
> and that is why I reference the http server), they are wasting their time trying to
> improve the pool code. There are clearly more serious memory allocation problems to solve
> first.
Then scratch that itch, Bill, instead of moaning about it.
> Gotta run. Party on...
My point exactly ;)
Re: pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> I have a problem with the original question though. I don't understand why
> anybody is trying to state that if people want to improve the pools code, they
> shouldn't, because we use malloc in one place in the code. People are
> free to work on whatever they want.
I am not being philosophical. Sure, people can spend their time doing whatever they want.
I assume open source developers like to see others benefit from their labor. If the goal
is to improve the performance of the http server, (remember this was posted to dev@httpd
and that is why I reference the http server), they are wasting their time trying to
improve the pool code. There are clearly more serious memory allocation problems to solve
first.
Gotta run. Party on...
Bill
Re: pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 25 August 2001 11:38, Sander Striker wrote:
> > > Btw, why couldn't we use pools in brigades again?
> >
> > Because of lifetimes. If you allocate buckets and brigades out of pools,
> > the lifetimes can't change, but bucket lifetimes aren't known at creation
> > time. And, you can't use the longest possible lifetime, because that
> > would be a leak.
>
> Ah, I suppose associating a pool with a brigade wouldn't work, would it?
> The buckets can move from brigade to brigade?
There is alreadya pool associated with a brigade. That doesn't get you
anything though. A bucket needs to be able to move from one brigade
to another.
I have a problem with the original question though. I don't understand why
anybody is trying to state that if people want to improve the pools code, they
shouldn't, because we use malloc in one place in the code. People are
free to work on whatever they want. If somebody wants to remove the malloc
calls from the buckets and bucket brigades, then they can, but that doesn't
mean that everybody has to focus on that.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 25 August 2001 11:38, Sander Striker wrote:
> > > Btw, why couldn't we use pools in brigades again?
> >
> > Because of lifetimes. If you allocate buckets and brigades out of pools,
> > the lifetimes can't change, but bucket lifetimes aren't known at creation
> > time. And, you can't use the longest possible lifetime, because that
> > would be a leak.
>
> Ah, I suppose associating a pool with a brigade wouldn't work, would it?
> The buckets can move from brigade to brigade?
There is alreadya pool associated with a brigade. That doesn't get you
anything though. A bucket needs to be able to move from one brigade
to another.
I have a problem with the original question though. I don't understand why
anybody is trying to state that if people want to improve the pools code, they
shouldn't, because we use malloc in one place in the code. People are
free to work on whatever they want. If somebody wants to remove the malloc
calls from the buckets and bucket brigades, then they can, but that doesn't
mean that everybody has to focus on that.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by Sander Striker <st...@apache.org>.
> > Btw, why couldn't we use pools in brigades again?
>
> Because of lifetimes. If you allocate buckets and brigades out of pools,
> the lifetimes can't change, but bucket lifetimes aren't known at creation
> time. And, you can't use the longest possible lifetime, because that
> would be a leak.
Ah, I suppose associating a pool with a brigade wouldn't work, would it?
The buckets can move from brigade to brigade?
> Ryan
Sander
pools and buckets/brigades, WAS: RE: Review of possible replacement for pools
Posted by Sander Striker <st...@apache.org>.
> > Btw, why couldn't we use pools in brigades again?
>
> Because of lifetimes. If you allocate buckets and brigades out of pools,
> the lifetimes can't change, but bucket lifetimes aren't known at creation
> time. And, you can't use the longest possible lifetime, because that
> would be a leak.
Ah, I suppose associating a pool with a brigade wouldn't work, would it?
The buckets can move from brigade to brigade?
> Ryan
Sander
Re: Review of possible replacement for pools
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 25 August 2001 11:26, Sander Striker wrote:
> > Why are we spending time trying to optimize pools when we haven't
> > eliminated the
> > malloc/frees in the bucket brigade calls? The miniscule
> > performance improvements
> > you -might- get optimizing pools will be completely obscured by
> > the overhead of the
> > malloc/frees.
> >
> > Bill
>
> Because it also eliminates the locking in the threaded mpm.
> And, I wanted to see if I could squeeze some extra performance
> out of it and make it a bit more readable. I don't know if
> I succeeded in the latter. Or the performance for that matter :)
>
> Btw, why couldn't we use pools in brigades again?
Because of lifetimes. If you allocate buckets and brigades out of pools,
the lifetimes can't change, but bucket lifetimes aren't known at creation
time. And, you can't use the longest possible lifetime, because that
would be a leak.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Review of possible replacement for pools
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 25 August 2001 11:26, Sander Striker wrote:
> > Why are we spending time trying to optimize pools when we haven't
> > eliminated the
> > malloc/frees in the bucket brigade calls? The miniscule
> > performance improvements
> > you -might- get optimizing pools will be completely obscured by
> > the overhead of the
> > malloc/frees.
> >
> > Bill
>
> Because it also eliminates the locking in the threaded mpm.
> And, I wanted to see if I could squeeze some extra performance
> out of it and make it a bit more readable. I don't know if
> I succeeded in the latter. Or the performance for that matter :)
>
> Btw, why couldn't we use pools in brigades again?
Because of lifetimes. If you allocate buckets and brigades out of pools,
the lifetimes can't change, but bucket lifetimes aren't known at creation
time. And, you can't use the longest possible lifetime, because that
would be a leak.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
RE: Review of possible replacement for pools
Posted by Sander Striker <st...@apache.org>.
> Why are we spending time trying to optimize pools when we haven't
> eliminated the
> malloc/frees in the bucket brigade calls? The miniscule
> performance improvements
> you -might- get optimizing pools will be completely obscured by
> the overhead of the
> malloc/frees.
>
> Bill
Because it also eliminates the locking in the threaded mpm.
And, I wanted to see if I could squeeze some extra performance
out of it and make it a bit more readable. I don't know if
I succeeded in the latter. Or the performance for that matter :)
Btw, why couldn't we use pools in brigades again?
Sander
RE: Review of possible replacement for pools
Posted by Sander Striker <st...@apache.org>.
> Why are we spending time trying to optimize pools when we haven't
> eliminated the
> malloc/frees in the bucket brigade calls? The miniscule
> performance improvements
> you -might- get optimizing pools will be completely obscured by
> the overhead of the
> malloc/frees.
>
> Bill
Because it also eliminates the locking in the threaded mpm.
And, I wanted to see if I could squeeze some extra performance
out of it and make it a bit more readable. I don't know if
I succeeded in the latter. Or the performance for that matter :)
Btw, why couldn't we use pools in brigades again?
Sander
Re: Review of possible replacement for pools
Posted by Bill Stoddard <bi...@wstoddard.com>.
Why are we spending time trying to optimize pools when we haven't eliminated the
malloc/frees in the bucket brigade calls? The miniscule performance improvements
you -might- get optimizing pools will be completely obscured by the overhead of the
malloc/frees.
Bill
> Justin Erenkrantz wrote:
>
> >On Sat, Aug 25, 2001 at 08:05:03PM +0200, Sander Striker wrote:
> >
> >>Adding an option to apr_pool_create_ex to indicate that the pool is
> >>going to be shared across threads would be an option I can certainly
> >>live with. OTOH, this will introduce an extra if(lock) pair in the
> >>apr_palloc and apr_pcalloc calls. I'll send in a patch later on.
> >>
> >
> >If you aren't shared, you have an extra NULL-check. I think that is
> >acceptable. If you are shared, we make sure we can't get trounced.
> >
> I agree, as long as the NULL-check doesn't measurably impact
> performance. One of the key success factors for the original pool
> code is the very short code path in the common case where it doesn't
> need to allocate new blocks. Adding another branch to this code
> path might or might not slow it down measurably--but we can find
> out through benchmarking.
>
> --Brian
>
>
>