Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit

[Laura Abbott <labbott@redhat.com>]

On 01/24/2016 11:08 PM, Joonsoo Kim wrote:
> Hello,
>
> 2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@cmpxchg.org>:
>> Hi,
>>
>> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote:
>>> * CMA allocator issues:
>>>    (1) order zero allocation failures:
>>>        We are observing order zero non-movable allocation failures in kernel
>>> with CMA configured. We don't start a reclaim because our free memory check
>>> does not consider free_cma. Hence the reclaim code assume we have enough free
>>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would
>>> like to discuss the challenges in getting this merged upstream.
>>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA)
>
> As far as I know, there is no disagreement on this patchset in last year LSF/MM.
> Problem may be due to my laziness... Sorry about that. I will handle it soon.
> Is there anything more that you concern?
>

Is that series going to conflict with the work done for ZONE_DEVICE or run
into similar problems?
033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory")
has commit text about running out of ZONE_SHIFT bits and needing to get
rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same
problem.

Thanks,
Laura
  
>> The exclusion of cma pages from the watermark checks means that
>> reclaim is happening too early, not too late, which leaves memory
>> underutilized. That's what ZONE_CMA set out to fix.
>>
>> But unmovable allocations can still fail when the only free memory is
>> inside CMA regions. I don't see how ZONE_CMA would fix that.
>>
>> CC Joonsoo
>
> I understand what Aneesh's problem is.
>
> Assume that
>
> X = non movable free page
> Y = movable free page
> Z = cma free page
>
> X < min watermark
> X + Y > high watermark
> Z > high watermark
>
> If there are bunch of consecutive movable allocation requests,
> Y will decrease. After some time, Y will be exhausted. At that
> time, there is enough Z so movable allocation request still can be
> handled in fastpath and kswapd isn't waked up. In that situation,
> if atomic non-movable page allocation for order-0 comes,
> it would be failed.
>
> Although it isn't mentioned on ZONE_CMA patchset, it is also
> fixed by that patchset because with that patchset, all CMA pages
> are in CMA zone so freepage calculation is always precise.
>
> Thanks.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>