Re: Pool freelist
On Thursday 04 September 2014 01:07:49, Branko Čibej wrote: On 03.09.2014 23:15, Stefan Fritsch wrote: On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote: It's now ~6 years later and so wondering if just bypassing the pool freelist is now viable, at least as a compile-time (or allocator) option. I don't see any reason against a non-default compile-time option. Then people could test it more easily and give feedback. I do. Distro packages will tend to pick one or the other option, and if applications have no control over the behaviour, they'll mysteriously behave differently on different platforms (or even different distros of the same OS). Unfortunately without a compile time option, you won't get enough testing. And any significant change in the allocator will cause a problem in some workload. We had, and possibly still have, the same problem with using mmap for pool allocation; I've seen an application mysteriously fail on some Linux distro because it ran out of file handles, but turned out to be hitting a hard limit of the number of mmapped blocks (i.e., pools) per process. Because the distro packager happened to turn mmap for pools on at compile time. I could never reproduce that issue. AFAICT, it is/was a kernel bug in some Linux versions. And the mmap allocator behaves significantly better in general (at least for httpd). Maybe it should be made the default, at least on linux. I don't think it's a good idea to put potential heisenbugs into the code by design. :) -- Brane
Re: Pool freelist
As I recall, Paul tested using tcmalloc or some other allocator to replace apr_palloc(). No bueno. The short answer is that pool-based allocation is *wicked* fast, compared to any other attempt/mechanism for allocating memory. I managed to improve over apr by removing an if-test or two, but any other approach will be comparatively/miserably slow. Now, that said: it sounds like you're not asking about apr_palloc(), but really about apr_pool_create(). I believe that would likely be just fine for something like HTTPD. On a per-request basis, it doesn't really allocate many pools. But Subversion tends to create a pool for any for-loop that might allocate memory. *Thousands* get created/destroyed across some Subversion operation. On the client, another microsecond isn't going to be a big deal, but the server exhibits this behavior too. Is your goal to remove the burdens, and simplify the codebase? Or .. ??? Cheers, -g On Wed, Sep 3, 2014 at 2:37 PM, Jim Jagielski j...@jagunet.com wrote: Yeah, that thread, and Greg's work w/ pocore, are kind of the origins of this question. The thing is that awhile ago, (I mean way awhile ago), I recall us trying to simply replace pools w/ malloc/free (Paul was the main dude in this case) and we got terrible performance... It's now ~6 years later and so wondering if just bypassing the pool freelist is now viable, at least as a compile-time (or allocator) option. On Sep 3, 2014, at 3:11 PM, Ivan Zhakov chemo...@gmail.com wrote: On 2 September 2014 16:02, Jim Jagielski j...@jagunet.com wrote: Has anyone looked at simply disabling the apr_pools freelist totally lately and seeing what the performance is? This thread may be interesting: http://svn.haxx.se/dev/archive-2008-10/0070.shtml We also tested disabling apr_pools free list in our Subversion distribution for Windows and didn't noticed performance problems on simple tests. We didn't performed proper benchmarks and decided to keep standard APR pools, but with very low MaxMemFree value. -- Ivan Zhakov
Re: Pool freelist
On 3 September 2014 23:37, Jim Jagielski j...@jagunet.com wrote: Yeah, that thread, and Greg's work w/ pocore, are kind of the origins of this question. The thing is that awhile ago, (I mean way awhile ago), I recall us trying to simply replace pools w/ malloc/free (Paul was the main dude in this case) and we got terrible performance... Simply replacing pools within malloc/free is not good idea IMO, because nice thing about pools that it has very good performance for small allocations because data allocated with minimum 8kb chunks. So it benefits for typical code like this: [[ some_t *s = apr_pcalloc(pool, sizeof(*s)); s-string1 = apr_pstrdup(pool, s); s-something = arp_pcalloc(pool, 11) ]] -- Ivan Zhakov
Re: Pool freelist
On Sep 4, 2014, at 7:03 AM, Ivan Zhakov i...@visualsvn.com wrote: On 3 September 2014 23:37, Jim Jagielski j...@jagunet.com wrote: Yeah, that thread, and Greg's work w/ pocore, are kind of the origins of this question. The thing is that awhile ago, (I mean way awhile ago), I recall us trying to simply replace pools w/ malloc/free (Paul was the main dude in this case) and we got terrible performance... Simply replacing pools within malloc/free is not good idea IMO That's not what is being proposed.
Re: Pool freelist
On 2 September 2014 16:02, Jim Jagielski j...@jagunet.com wrote: Has anyone looked at simply disabling the apr_pools freelist totally lately and seeing what the performance is? This thread may be interesting: http://svn.haxx.se/dev/archive-2008-10/0070.shtml We also tested disabling apr_pools free list in our Subversion distribution for Windows and didn't noticed performance problems on simple tests. We didn't performed proper benchmarks and decided to keep standard APR pools, but with very low MaxMemFree value. -- Ivan Zhakov
Re: Pool freelist
Yeah, that thread, and Greg's work w/ pocore, are kind of the origins of this question. The thing is that awhile ago, (I mean way awhile ago), I recall us trying to simply replace pools w/ malloc/free (Paul was the main dude in this case) and we got terrible performance... It's now ~6 years later and so wondering if just bypassing the pool freelist is now viable, at least as a compile-time (or allocator) option. On Sep 3, 2014, at 3:11 PM, Ivan Zhakov chemo...@gmail.com wrote: On 2 September 2014 16:02, Jim Jagielski j...@jagunet.com wrote: Has anyone looked at simply disabling the apr_pools freelist totally lately and seeing what the performance is? This thread may be interesting: http://svn.haxx.se/dev/archive-2008-10/0070.shtml We also tested disabling apr_pools free list in our Subversion distribution for Windows and didn't noticed performance problems on simple tests. We didn't performed proper benchmarks and decided to keep standard APR pools, but with very low MaxMemFree value. -- Ivan Zhakov
Re: Pool freelist
On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote: It's now ~6 years later and so wondering if just bypassing the pool freelist is now viable, at least as a compile-time (or allocator) option. I don't see any reason against a non-default compile-time option. Then people could test it more easily and give feedback. Cheers, Stefan
Re: Pool freelist
On 03.09.2014 23:15, Stefan Fritsch wrote: On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote: It's now ~6 years later and so wondering if just bypassing the pool freelist is now viable, at least as a compile-time (or allocator) option. I don't see any reason against a non-default compile-time option. Then people could test it more easily and give feedback. I do. Distro packages will tend to pick one or the other option, and if applications have no control over the behaviour, they'll mysteriously behave differently on different platforms (or even different distros of the same OS). We had, and possibly still have, the same problem with using mmap for pool allocation; I've seen an application mysteriously fail on some Linux distro because it ran out of file handles, but turned out to be hitting a hard limit of the number of mmapped blocks (i.e., pools) per process. Because the distro packager happened to turn mmap for pools on at compile time. I don't think it's a good idea to put potential heisenbugs into the code by design. :) -- Brane
Pool freelist
Has anyone looked at simply disabling the apr_pools freelist totally lately and seeing what the performance is?
