apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: svn commit: r1788334 - in /apr/apr/trunk: CHANGES include/apr_allocator.h memory/unix/apr_pools.c
Date Sun, 02 Apr 2017 10:05:16 GMT
On 28 March 2017 at 20:24, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Tue, Mar 28, 2017 at 2:39 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:
>> I'm not sure that *actual* allocation size could be predicted in all
>> cases and possible apr_allocator_t implementation.
> Is there multiple apr_allocator_t implementations?
Currently at least two modes: heap-based and mmap-based.

>> Currently
>> apr_bucket_alloc_aligned_floor() and apr_bucket_alloc() logic should
>> be kept in sync, which is error prone imho.
> I'd say that thanks to apr_allocator_align() they at least do not
> depend on the allocator internals (look at the big assumption in the
> !APR_VERSION_AT_LEAST(1,6,0) case in
> apr_bucket_alloc_aligned_floor()...).
> If one changes SMALL_NODE_SIZE or SIZEOF_NODE_HEADER_T it should
> continue to work, but yes if the bucket_alloc implementation changes
> radically it may break (I hope that before such change one would grep
> I don't see how we couldn't implement any new version of
> apr_bucket_alloc_aligned_floor() though, some specific example of such
> a breaking change?
>> After looking to apr_bucket_alloc code I suggest to add
>> apr_bucket_node_size(const void *node) that returns actual allocated
>> node size. apr_file_bucket implementation could allocate desired
>> buffer size and then query actual allocated size via
>> apr_bucket_node_size. Apache Serf bucket_allocator uses similar
>> approach.
> That's still after the allocation took place.
I think it's a good thing: it's always better to rely on actual
behavior, than try to predict it.

Do not forget that apr_allocator_t has at least two modes: use heap or use mmap.

> Let's say a user configures the buffer size of file buckets to 8192
> bytes (users like powers of two ;)
The opposite situation may happen if user configure size of buffer
like 12000 bytes: in this case actual buffer would be ~ 8100 bytes.
Also apr_allocator_t has list of free nodes and may return larger node
than requested. Why waste this memory?

> With the help apr_bucket_alloc_aligned_floor() we can allocate exactly
> 8192 bytes, yet have only ~8100 of them available for reads (a bit
> like APR_BUCKET_BUFF_SIZE=8000 takes allocators overhead into account,
> approximately...).
> With your method, we'd allocate 12288 bytes, but either use only 3/4
> of them (internal fragmentation), or really try to read ~12200 bytes,
> in both cases this is more than what the user asked.
> I tend to think that the configured value is an upper bound, more
> related to some controlled memory consumption (or some device
> capacity) than anything.
I'm not sure that user configures an upper bound.

Ivan Zhakov

View raw message