Re: [PATCH v3 0/4] Fix HugeTLB subpool used_hpages tracking

[Ackerley Tng]

Ackerley Tng <ackerleytng@xxxxxxxxxx> writes:

>
> [...snip...]
>
>> 2. On splitting: 1/4 applies cleanly on top of both queued fixes, but
>>    in my tests it made min_size-only mounts worse on its own. As far
>>    as I can tell, that's because it starts tracking used_hpages on
>>    those mounts, while the two error paths only release it after 2/4
>>    and 3/4.
>>
>>    HugePages_Rsvd, expected value in parentheses. Q = the two queued
>>    fixes, wrap = 18446744073709551615:
>>
>>                                    rc3   +Q  +1/4  +Q+1/4  +1/4..4/4
>>    min_size=4M only:
>>      SIGBUS faults [1], no files (2)  2    2     0      0      2
>>    min_size=8M only:
>>      failed mmap [2], umounted (0)    0    0     3      3      0
>>    size=8M,min_size=4M:
>>      SIGBUS faults [1], no files (2)  0    0     0      0      2
>>    size=10M,min_size=8M:
>>      failed mmap [2], umounted (0)  wrap   0  wrap      0      0
>>
>>    With 1/4 alone, the min_size-only mount loses its reservation, and
>>    in the failed-mmap case three huge pages stay reserved after umount,
>>    presumably because the subpool is never freed.
>>
>> So it looks to me like 1/4 shouldn't go anywhere without 2/4 and 3/4.
>
> Thanks for testing this! IIUC from your table, 1/4 introduces
> regressions.
>
> How do we handle this, should I squash patches 1/2/3 together, or is
> there some way to use the Fixes: tags to require those 3 to go together?
>

I think I have a better way to organize the 4 patches and the two
already queued. Will work on this.

>
> [...snip...]
>