Re: Re: Re: [PATCH] mm: Add nr_free_highatomimic to fix incorrect watermatk routine

[Michal Hocko]

On Tue 03-09-19 18:59:59, Park Sangwoo wrote:
> >On Mon 02-09-19 13:34:54, Sangwooï wrote:
> >>>On Fri 30-08-19 18:25:53, Sangwoo wrote:
> >>>> 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.
> >>>> So, if we except total block size of highatomic, it's twice minus size of
> >>allocated
> >>>> 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
> >> (GFP_HIGHUSER_MOVABLE), nodemask=(null)
> >>>>  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?
> 
> 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. 
[...]
> 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
SUSE Labs