Laura Abbott <labbott@xxxxxxxxxx> writes: > On 01/22/2016 06:19 AM, Jan Kara wrote: >> On Fri 22-01-16 20:17:07, Balbir Singh wrote: >>> On Fri, 22 Jan 2016 10:11:12 +0530 >>> "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: >>> >>>> Hi, >>>> >>>> I would like to attend LSF/MM this year (2016). >>>> >>>> My main interest is in MM related topics although I am also interested >>>> in the btrfs status discussion (particularly related to subpage size block >>>> size topic), if we are having one. Most of my recent work in the kernel is >>>> related to adding ppc64 support for different MM features. My current focus >>>> is on adding Linux support for the new radix MMU model of Power9. >>>> >>>> Topics of interest include: >>>> >>>> * 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) >>>> >>>> Others needed for the discussion: >>>> Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> >>>> >>>> (2) CMA allocation failures due to pinned pages in the region: >>>> We allow only movable allocation from the CMA region to enable us >>>> to migrate those pages later when we get a CMA allocation request. But >>>> if we pin those movable pages, we will fail the migration which can result >>>> in CMA allocation failure. One such report can be found here. >>>> http://article.gmane.org/gmane.linux.kernel.mm/136738 >>>> >>>> Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would >>>> like to discuss what needs to be done to get this patch series merged upstream >>>> https://lkml.org/lkml/2014/5/26/345 (VM_PINNED) >>>> >>>> Others needed for the discussion: >>>> Peter Zijlstra <peterz@xxxxxxxxxxxxx> >>> >>> +1 >>> >>> I agree CMA design is a concern. I also noticed that today all CMA pages come >>> from one node. On a NUMA box you'll see cross traffic going to that region - >>> although from kernel only text. It should be discussed at the summit and Aneesh >>> would be a good representative >> >> I'm not really an mm guy but CMA has been discussed already last year, and >> I think even the year before... Are we moving somewhere? So if this is >> about hashing out what blocks VM_PINNED series (I think it may be just a >> lack of Peter's persistence in pushing it ;) then that looks like a >> sensible goal. Some other CMA architecture discussions need IMHO a more >> concrete proposals... >> >> Honza >> > > The conclusion from the CMA session last year was that pinned pages need to be > fixed up at the caller sites doing the pinning. Each caller site really needs > to be taken individually. I think the discussion last year was good but if > it's going to end up with a different conclusion I agree there needs to be > concrete proposals. But that was not what was suggested in the kvm guest ram pin due to vfio thread I linked above. I think we still need to have an agreement on whether the callers should be migrating the pages or a generic framework like VM_PINNED is needed. > > Something that could be worth discussing as well is Joonsoo Kim's proposal for > page reference tracking http://thread.gmane.org/gmane.linux.kernel.api/16138 > > Thanks, > Laura -- 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>