Hello, On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: > On 10/16/2014 10:55 AM, Laura Abbott wrote: > >On 10/15/2014 8:35 PM, Hui Zhu wrote: > > > >It's good to see another proposal to fix CMA utilization. Do you have > >any data about the success rate of CMA contiguous allocation after > >this patch series? I played around with a similar approach of using > >CMA for MIGRATE_MOVABLE allocations and found that although utilization > >did increase, contiguous allocations failed at a higher rate and were > >much slower. I see what this series is trying to do with avoiding > >allocation from CMA pages when a contiguous allocation is progress. > >My concern is that there would still be problems with contiguous > >allocation after all the MIGRATE_MOVABLE fallback has happened. > > Hi, > > did anyone try/suggest the following idea? > > - keep CMA as fallback to MOVABLE as is is now, i.e. non-agressive > - when UNMOVABLE (RECLAIMABLE also?) allocation fails and CMA > pageblocks have space, don't OOM immediately, but first try to > migrate some MOVABLE pages to CMA pageblocks, to make space for the > UNMOVABLE allocation in non-CMA pageblocks > - this should keep CMA pageblocks free as long as possible and > useful for CMA allocations, but without restricting the non-MOVABLE > allocations even though there is free memory (but in CMA pageblocks) > - the fact that a MOVABLE page could be successfully migrated to CMA > pageblock, means it was not pinned or otherwise non-migratable, so > there's a good chance it can be migrated back again if CMA > pageblocks need to be used by CMA allocation I suggested exactly same idea long time ago. > - it's more complex, but I guess we have most of the necessary > infrastructure in compaction already :) I agree but still, it doesn't solve reclaim problem(ie, VM doesn't need to reclaim CMA pages when memory pressure of unmovable pages happens). Of course, we could make VM be aware of that via introducing new flag of __isolate_lru_page. However, I'd like to think CMA design from the beginning. It made page allocation logic complicated, even very fragile as we had recently and now we need to add new logics to migrate like you said. As well, we need to fix reclaim path, too. It makes mm complicated day by day even though it doesn't do the role enough well(ie, big latency and frequent allocation failure) so I really want to stop making the mess bloated. Long time ago, when I saw Joonsoo's CMA agressive allocation patchset (ie, roundrobin allocation between CMA and normal movable pages) it was good to me at a first glance but it needs tweak of allocation path and doesn't solve reclaim path, either. Yes, reclaim path could be solved by another patch but I want to solve it altogether. At that time, I suggested big surgery to Joonsoo in offline that let's move CMA allocation with movable zone allocation. With it, we could make allocation/reclaim path simple but thing is we should make VM be aware of overlapping MOVABLE zone which means some of pages in the zone could be part of another zones but I think we already have logics to handle it when I read comment in isolate_freepages so I think the design should work. A thing you guys might worry is bigger CMA latency because it makes CMA memory usage ratio higher than the approach you mentioned but anyone couldn't guarantee it once memory is fully utilized. In addition, we have used fair zone allocator policy so it makes round robin allocation automatically so I believe it should be way to go. > > Thoughts? > Vlastimil > > >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> -- Kind regards, Minchan Kim -- 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>