> Am 14.10.2021 um 11:23 schrieb Ruediger Pluem <rpl...@apache.org>:
>
>
>
> 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 :-)
Isn't that what "EnableMMAP off" is for?
>
>
> Regards
>
> Rüdiger
>
