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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

2016-01-23 1:38 GMT+09:00 Johannes Weiner <hannes@xxxxxxxxxxx>:
> 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?

> 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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]