On 10/14/21 11:26 AM, ste...@eissing.org wrote:
>
>
>> 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?
>From my point of view not really. MMap does not work well with files on
>certain network file systems like NFS if file sizes change
while the file is open. This could cause core dumps. Hence the possibility to
switch it off.
Regards
Rüdiger
