On 2017/4/11 11:17, js1304@xxxxxxxxx wrote: > From: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > Changed from v6 > o Rebase on next-20170405 > o Add a fix for lowmem mapping on ARM (last patch) > o Re-organize the cover letter > > Changes from v5 > o Rebase on next-20161013 > o Cosmetic change on patch 1 > o Optimize span of ZONE_CMA on multiple node system > > Changes from v4 > o Rebase on next-20160825 > o Add general fix patch for lowmem reserve > o Fix lowmem reserve ratio > o Fix zone span optimizaion per Vlastimil > o Fix pageset initialization > o Change invocation timing on cma_init_reserved_areas() > > Changes from v3 > o Rebase on next-20160805 > o Split first patch per Vlastimil > o Remove useless function parameter per Vlastimil > o Add code comment per Vlastimil > o Add following description on cover-letter > > Changes from v2 > o Rebase on next-20160525 > o No other changes except following description > > Changes from v1 > o Separate some patches which deserve to submit independently > o Modify description to reflect current kernel state > (e.g. high-order watermark problem disappeared by Mel's work) > o Don't increase SECTION_SIZE_BITS to make a room in page flags > (detailed reason is on the patch that adds ZONE_CMA) > o Adjust ZONE_CMA population code > > > Hello, > > This is the 7th version of ZONE_CMA patchset. One patch is added > to fix potential problem on ARM. Other changes are just due to rebase. > > This patchset has long history and got some reviews before. This > cover-letter has the summary and my opinion on those reviews. Content > order is so confusing so I make a simple index. If anyone want to > understand the history properly, please read them by reverse order. > > PART 1. Strong points of the zone approach > PART 2. Summary in LSF/MM 2016 discussion > PART 3. Original motivation of this patchset > > ***** PART 1 ***** > > CMA has many problems and I mentioned them on the bottom of the > cover letter. These problems comes from limitation of CMA memory that > should be always migratable for device usage. I think that introducing > a new zone is the best approach to solve them. Here are the reasons. > > Zone is introduced to solve some issues due to H/W addressing limitation. > MM subsystem is implemented to work efficiently with these zones. > Allocation/reclaim logic in MM consider this limitation very much. > What I did in this patchset is introducing a new zone and extending zone's > concept slightly. New concept is that zone can have not only H/W addressing > limitation but also S/W limitation to guarantee page migration. > This concept is originated from ZONE_MOVABLE and it works well > for a long time. So, ZONE_CMA should not be special at this moment. > > There is a major concern from Mel that ZONE_MOVABLE which has > S/W limitation causes highmem/lowmem problem. Highmem/lowmem problem is > that some of memory cannot be usable for kernel memory due to limitation > of the zone. It causes to break LRU ordering and makes hard to find kernel > usable memory when memory pressure. > > However, important point is that this problem doesn't come from > implementation detail (ZONE_MOVABLE/MIGRATETYPE). Even if we implement it > by MIGRATETYPE instead of by ZONE_MOVABLE, we cannot use that type of > memory for kernel allocation because it isn't migratable. So, it will cause > to break LRU ordering, too. We cannot avoid the problem in any case. > Therefore, we should focus on which solution is better for maintenance > and not intrusive for MM subsystem. > > In this viewpoint, I think that zone approach is better. As mentioned > earlier, MM subsystem already have many infrastructures to deal with > zone's H/W addressing limitation. Adding S/W limitation on zone concept > and adding a new zone doesn't change anything. It will work by itself. > My patchset can remove many hooks related to CMA area management in MM > while solving the problems. More hooks are required to solve the problems > if we choose MIGRATETYPE approach. > Agree, there are already too many hooks and pain to maintain/bugfix. It looks better if choose this ZONE_CMA approach. -- Regards, Bob Liu -- 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>
