mm: Add nr_free_highatomimic to fix incorrect watermatk routine

PATCH Park Sangwoo 2 participants 2 messages Sep 4, 2019 Memory management

Share & tools

Park Sangwoo

author

2019-09-04 06:55 UTC #0 lore raw

Quoted 31 lines · Park Sangwoo

Quoted 30 lines · Sangwoo�
Quoted 28 lines
Quoted 15 lines · Sangwoo
Quoted 5 lines
The highatomic migrate block can be increased to 1% of Total memory. And, this is for only highorder ( > 0 order). So, this block size is excepted during check watermark if allocation type isn't alloc_harder.
It has problem. The usage of highatomic is already calculated at
NR_FREE_PAGES.
Quoted 1 line
Quoted 1 line
So, if we except total block size of highatomic, it's twice minus size of
allocated
Quoted 6 lines
Quoted 6 lines
highatomic.
It's cause allocation fail although free pages enough.
We checked this by random test on my target(8GB RAM).
Binder:6218_2: page allocation failure: order:0, mode:0x14200ca
Quoted 8 lines
(GFP_HIGHUSER_MOVABLE), nodemask=(null)
Quoted 5 lines
Quoted 1 line
Binder:6218_2 cpuset=background mems_allowed=0
How come this order-0 sleepable allocation fails? The upstream kernel doesn't fail those allocations unless the process context is killed by the oom killer.
Most calltacks are zsmalloc, as shown below.
What makes those allocations special so that they fail unlike any other normal order-0 requests? Also do you see the same problem with the current upstream kernel? Is it possible this is an Android specific issue?

Quoted 8 lines

Quoted 3 lines
There is the other case of fail order-0 fail.
----
hvdcp_opti: page allocation failure: order:0, mode:0x1004000(GFP_NOWAIT|__GFP_COMP), nodemask=(null)
This is an atomic allocation and failing that one is not a problem usually. High atomic reservations might prevent GFP_NOWAIT allocation from suceeding but I do not see that as a problem. This is the primary purpose of the reservation.

Thanks, your answer helped me. However, my suggestion is not to modify the use and management of the high atomic region, but to calculate the exact free size of the highatomic so that fail does not occur for previously shared cases.

In __zone_water_mark_ok(...) func, if it is not atomic allocation, high atomic size is excluded.

bool __zone_watermark_ok(struct zone *z,
...

{
    ...
    if (likely(!alloc_harder)) {
        free_pages -= z->nr_reserved_highatomic;
    ...
}

However, free_page excludes the size already allocated by hiahtomic. If highatomic block is small(Under 4GB RAM), it could be no problem. But, the larger the memory size, the greater the chance of problems. (Becasue highatomic size can be increased up to 1% of memory)

Quoted 9 lines

[...]
Quoted 5 lines
In my test, most case are using camera. So, memory usage is increased momentarily, it cause free page go to under low value of watermark.
If free page is under low and 0-order fail is occured, its normal operation. But, although free page is higher than min, fail is occurred.
After fix routin for checking highatomic size, it's not reproduced.
But you are stealing from the atomic reserves and thus defeating the purpose of it.

Michal Hocko

2019-09-04 08:19 UTC #1 lore raw

Quoted 54 lines · Park Sangwoo

Quoted 31 lines · Park Sangwoo
Quoted 30 lines · Sangwoo�
Quoted 28 lines
Quoted 15 lines · Sangwoo
Quoted 5 lines
The highatomic migrate block can be increased to 1% of Total memory. And, this is for only highorder ( > 0 order). So, this block size is excepted during check watermark if allocation type isn't alloc_harder.
It has problem. The usage of highatomic is already calculated at
NR_FREE_PAGES.
Quoted 1 line
Quoted 1 line
So, if we except total block size of highatomic, it's twice minus size of
allocated
Quoted 6 lines
Quoted 6 lines
highatomic.
It's cause allocation fail although free pages enough.
We checked this by random test on my target(8GB RAM).
Binder:6218_2: page allocation failure: order:0, mode:0x14200ca
Quoted 8 lines
(GFP_HIGHUSER_MOVABLE), nodemask=(null)
Quoted 5 lines
Quoted 1 line
Binder:6218_2 cpuset=background mems_allowed=0
How come this order-0 sleepable allocation fails? The upstream kernel doesn't fail those allocations unless the process context is killed by the oom killer.
Most calltacks are zsmalloc, as shown below.
What makes those allocations special so that they fail unlike any other normal order-0 requests? Also do you see the same problem with the current upstream kernel? Is it possible this is an Android specific issue?
Quoted 8 lines
Quoted 3 lines
There is the other case of fail order-0 fail.
----
hvdcp_opti: page allocation failure: order:0, mode:0x1004000(GFP_NOWAIT|__GFP_COMP), nodemask=(null)
This is an atomic allocation and failing that one is not a problem usually. High atomic reservations might prevent GFP_NOWAIT allocation from suceeding but I do not see that as a problem. This is the primary purpose of the reservation.
Thanks, your answer helped me. However, my suggestion is not to modify the use and management of the high atomic region, but to calculate the exact free size of the highatomic so that fail does not occur for previously shared cases.
In __zone_water_mark_ok(...) func, if it is not atomic allocation, high atomic size is excluded.
bool __zone_watermark_ok(struct zone *z,
...
{
    ...
    if (likely(!alloc_harder)) {
        free_pages -= z->nr_reserved_highatomic;
    ...
}

Quoted 4 lines

However, free_page excludes the size already allocated by hiahtomic. If highatomic block is small(Under 4GB RAM), it could be no problem. But, the larger the memory size, the greater the chance of problems. (Becasue highatomic size can be increased up to 1% of memory)

I still do not understand. NR_FREE_PAGES should include the amount of hhighatomic reserves, right. So reducing the free_pages for normal allocations just makes sense. Or what do I miss?

I am sorry but I find your reasoning really hard to follow.

Signature · 2 lines

Michal Hocko
SUSE Labs