On 28 March 2017 at 20:24, Yann Ylavic <ylavic....@gmail.com> wrote: > On Tue, Mar 28, 2017 at 2:39 PM, Ivan Zhakov <i...@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 > SMALL_NODE_SIZE and SIZEOF_NODE_HEADER_T in the file :) > > 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
