On 10/14/21 11:16 AM, ste...@eissing.org wrote:
>
>
>> Am 14.10.2021 um 11:07 schrieb Ruediger Pluem <rpl...@apache.org>:
>>
>>
>>
>> On 10/12/21 3:34 PM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Tue Oct 12 13:34:01 2021
>>> New Revision: 1894163
>>>
>>> static apr_off_t bucket_mem_used(apr_bucket *b)
>>> {
>>> - if (APR_BUCKET_IS_FILE(b)) {
>>> + if (APR_BUCKET_IS_FILE(b) || bucket_is_mmap(b)) {
>>
>> MMaped buckets also consume physical memory once the content was read. Of
>> course the pages can be dropped from physical memory
>> again if space is needed. Furthermore they consume address space in the
>> process, but I admit that this will unlikely cause
>> any issues on 64 bit architectures. The only thing that can happen here is
>> that people complain about large virtual memory sizes
>> of processes which has no real impact in this case.
>
> My (maybe faulty) reasoning here is:
> HTTP/2 does not create any FILE or MMAP buckets. It just wants to transfer
> them efficiently from c2 to c1. Instead of reading them and copying the
> chunks, it apr_mmap_dup() or apr_file_setaside() their content for the
> receiving bucket brigade.
>
> This should (as I understand it) not duplicate any memory or use more memory
> than in a HTTP/1.1 response (plus the usual h2 overhead).
Agreed, but reading consumers need to take care that they do not read too much
at once without dropping the mmap bucket(s) after
reading, but this is not mod_http2's responsibility.
This leaves only the address space issue, which should only matter on 32 bit
architectures in certain cases. So I guess this could
stay as is until people from non 64 bit platforms complain :-)
Regards
Rüdiger
