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

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

 



On 01/24/2016 11:08 PM, Joonsoo Kim wrote:
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?


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


--
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]