From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 16 Oct 2014 11:35:47 +0800 Message-ID: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Sender: owner-linux-mm@kvack.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu List-Id: linux-pm@vger.kernel.org In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of MIGRATE_MOVABLE. MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in order that Linux kernel want. If a system that has a lot of user space program is running, for instance, an Android board, most of memory is in MIGRATE_MOVABLE and allocated. Before function __rmqueue_fallback get memory from MIGRATE_CMA, the oom_killer will kill a task to release memory when kernel want get MIGRATE_UNMOVABLE memory because fallbacks of MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. This status is odd. The MIGRATE_CMA has a lot free memory but Linux kernel kill some tasks to release memory. This patch series adds a new function CMA_AGGRESSIVE to make CMA memory be more aggressive about allocation. If function CMA_AGGRESSIVE is available, when Linux kernel call function __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA doesn't have enough pages for allocation, go back to allocate memory from MIGRATE_MOVABLE. Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Date: Thu, 16 Oct 2014 11:35:48 +0800 Message-ID: <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu List-Id: linux-pm@vger.kernel.org Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK that depend on CMA_AGGRESSIVE. If physical memory size (not include CMA memory) in byte less than or equal to CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) will be opened. When system boot, this value will set to sysctl "vm.cma-aggressive-free-min". If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will be set to true when Linux boot. Signed-off-by: Hui Zhu --- mm/Kconfig | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 1d1ae6b..940f5f3 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -527,6 +527,49 @@ config CMA_AREAS If unsure, leave the default value "7". +config CMA_AGGRESSIVE + bool "CMA aggressive" + depends on CMA + default n + help + Be more aggressive about taking memory from CMA when allocate MOVABLE + page. + Sysctl "vm.cma-aggressive-switch", "vm.cma-aggressive-alloc-max" + and "vm.cma-aggressive-shrink-switch" can control this function. + If unsure, say "n". + +config CMA_AGGRESSIVE_PHY_MAX + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" + depends on CMA_AGGRESSIVE + default 0x40000000 + help + If physical memory size (not include CMA memory) in byte less than or + equal to this value, CMA aggressive switch will be opened. + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control + the CMA AGGRESSIVE switch. + +config CMA_AGGRESSIVE_FREE_MIN + int "The minimum free CMA page number that CMA aggressive work" + depends on CMA_AGGRESSIVE + default 500 + help + When system boot, this value will set to sysctl + "vm.cma-aggressive-free-min". + If the number of CMA free pages is small than this sysctl value, + CMA aggressive will not work. + +config CMA_AGGRESSIVE_SHRINK + bool "CMA aggressive shrink" + depends on CMA_AGGRESSIVE + default y + help + If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will + be set to true when Linux boot. + If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal + memory's size is smaller than the size that it want to allocate, + do memory shrink before driver allocate pages from CMA. + If unsure, say "y". + config MEM_SOFT_DIRTY bool "Track memory changes" depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Thu, 16 Oct 2014 11:35:49 +0800 Message-ID: <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: linux-kernel-owner@vger.kernel.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu List-Id: linux-pm@vger.kernel.org Function shrink_all_memory try to free `nr_to_reclaim' of memory. CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of memory. It need different scan_control with current caller function hibernate_preallocate_memory. If hibernation is true, the caller is hibernate_preallocate_memory. if not, the caller is CMA alloc function. Signed-off-by: Hui Zhu --- include/linux/swap.h | 3 ++- kernel/power/snapshot.c | 2 +- mm/vmscan.c | 19 +++++++++++++------ 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/include/linux/swap.h b/include/linux/swap.h index 37a585b..9f2cb43 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, gfp_t gfp_mask, bool noswap, struct zone *zone, unsigned long *nr_scanned); -extern unsigned long shrink_all_memory(unsigned long nr_pages); +extern unsigned long shrink_all_memory(unsigned long nr_pages, + bool hibernation); extern int vm_swappiness; extern int remove_mapping(struct address_space *mapping, struct page *page); extern unsigned long vm_total_pages; diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 791a618..a00fc35 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) * NOTE: If this is not done, performance will be hurt badly in some * test cases. */ - shrink_all_memory(saveable - size); + shrink_all_memory(saveable - size, true); /* * The number of saveable pages in memory was too high, so apply some diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..fdcfa30 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } -#ifdef CONFIG_HIBERNATION +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of * freed pages. @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) * LRU order by reclaiming preferentially * inactive > active > active referenced > active mapped */ -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) { struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, - .gfp_mask = GFP_HIGHUSER_MOVABLE, .priority = DEF_PRIORITY, - .may_writepage = 1, .may_unmap = 1, .may_swap = 1, - .hibernation_mode = 1, }; struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); struct task_struct *p = current; unsigned long nr_reclaimed; + if (hibernation) { + sc.hibernation_mode = 1; + sc.may_writepage = 1; + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; + } else { + sc.hibernation_mode = 0; + sc.may_writepage = !laptop_mode; + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; + } + p->flags |= PF_MEMALLOC; lockdep_set_current_reclaim_state(sc.gfp_mask); reclaim_state.reclaimed_slab = 0; @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) return nr_reclaimed; } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Date: Thu, 16 Oct 2014 11:35:50 +0800 Message-ID: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu List-Id: linux-pm@vger.kernel.org Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and cma_aggressive_shrink_switch. cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be controlled by sysctl vm.cma-aggressive-switch. cma_aggressive_free_min can be controlled by sysctl "vm.cma-aggressive-free-min". If the number of CMA free pages is small than this sysctl value, CMA_AGGRESSIVE will not work in page alloc code. cma_aggressive_shrink_switch can be controlled by sysctl "vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal memory's size is smaller than the size that it want to allocate, do memory shrink with function shrink_all_memory before driver allocate pages from CMA. When Linux kernel try to reserve custom contiguous area, increase the value of cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code. After reserve custom contiguous area function return, decreases the value of cma_alloc_counter. Signed-off-by: Hui Zhu --- include/linux/cma.h | 7 +++++++ kernel/sysctl.c | 27 +++++++++++++++++++++++++++ mm/cma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) diff --git a/include/linux/cma.h b/include/linux/cma.h index 0430ed0..df96abf 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -15,6 +15,13 @@ struct cma; +#ifdef CONFIG_CMA_AGGRESSIVE +extern atomic_t cma_alloc_counter; +extern int cma_aggressive_switch; +extern unsigned long cma_aggressive_free_min; +extern int cma_aggressive_shrink_switch; +#endif + extern phys_addr_t cma_get_base(struct cma *cma); extern unsigned long cma_get_size(struct cma *cma); diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 4aada6d..646929e2 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -92,6 +92,10 @@ #include #endif +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + #if defined(CONFIG_SYSCTL) @@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_CMA_AGGRESSIVE + { + .procname = "cma-aggressive-switch", + .data = &cma_aggressive_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, + { + .procname = "cma-aggressive-free-min", + .data = &cma_aggressive_free_min, + .maxlen = sizeof(unsigned long), + .mode = 0600, + .proc_handler = proc_doulongvec_minmax, + }, + { + .procname = "cma-aggressive-shrink-switch", + .data = &cma_aggressive_shrink_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, +#endif { } }; diff --git a/mm/cma.c b/mm/cma.c index 963bc4a..566ed5f 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -33,6 +33,7 @@ #include #include #include +#include struct cma { unsigned long base_pfn; @@ -127,6 +128,27 @@ err: return -EINVAL; } +#ifdef CONFIG_CMA_AGGRESSIVE +/* The counter for the dma_alloc_from_contiguous and + dma_release_from_contiguous. */ +atomic_t cma_alloc_counter = ATOMIC_INIT(0); + +/* Swich of CMA_AGGRESSIVE. */ +int cma_aggressive_switch __read_mostly; + +/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE will + not work. */ +#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN +unsigned long cma_aggressive_free_min __read_mostly = + CONFIG_CMA_AGGRESSIVE_FREE_MIN; +#else +unsigned long cma_aggressive_free_min __read_mostly = 500; +#endif + +/* Swich of CMA_AGGRESSIVE shink. */ +int cma_aggressive_shrink_switch __read_mostly; +#endif + static int __init cma_init_reserved_areas(void) { int i; @@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void) return ret; } +#ifdef CONFIG_CMA_AGGRESSIVE + cma_aggressive_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX + if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX) +#else + if (memblock_phys_mem_size() <= 0x40000000) +#endif + cma_aggressive_switch = 1; + + cma_aggressive_shrink_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK + if (cma_aggressive_switch) + cma_aggressive_shrink_switch = 1; +#endif +#endif + return 0; } core_initcall(cma_init_reserved_areas); @@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) unsigned long bitmap_maxno, bitmap_no, bitmap_count; struct page *page = NULL; int ret; +#ifdef CONFIG_CMA_AGGRESSIVE + int free = global_page_state(NR_FREE_PAGES) + - global_page_state(NR_FREE_CMA_PAGES) + - totalreserve_pages; +#endif if (!cma || !cma->count) return NULL; @@ -326,6 +369,13 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) bitmap_maxno = cma_bitmap_maxno(cma); bitmap_count = cma_bitmap_pages_to_bits(cma, count); +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_inc(&cma_alloc_counter); + if (cma_aggressive_switch && cma_aggressive_shrink_switch + && free < count) + shrink_all_memory(count - free, false); +#endif + for (;;) { mutex_lock(&cma->lock); bitmap_no = bitmap_find_next_zero_area(cma->bitmap, @@ -361,6 +411,10 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) start = bitmap_no + mask + 1; } +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_dec(&cma_alloc_counter); +#endif + pr_debug("%s(): returned %p\n", __func__, page); return page; } -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Date: Thu, 16 Oct 2014 11:35:51 +0800 Message-ID: <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu List-Id: linux-pm@vger.kernel.org If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. Signed-off-by: Hui Zhu --- mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 736d8e1..87bc326 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -65,6 +65,10 @@ #include #include "internal.h" +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ static DEFINE_MUTEX(pcp_batch_high_lock); #define MIN_PERCPU_PAGELIST_FRACTION (8) @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, { struct page *page; -retry_reserve: +#ifdef CONFIG_CMA_AGGRESSIVE + if (cma_aggressive_switch + && migratetype == MIGRATE_MOVABLE + && atomic_read(&cma_alloc_counter) == 0 + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min + + (1 << order)) + migratetype = MIGRATE_CMA; +#endif +retry: page = __rmqueue_smallest(zone, order, migratetype); - if (unlikely(!page) && migratetype != MIGRATE_RESERVE) { - page = __rmqueue_fallback(zone, order, migratetype); + if (unlikely(!page)) { +#ifdef CONFIG_CMA_AGGRESSIVE + if (migratetype == MIGRATE_CMA) { + migratetype = MIGRATE_MOVABLE; + goto retry; + } +#endif + if (migratetype != MIGRATE_RESERVE) { + page = __rmqueue_fallback(zone, order, migratetype); - /* - * Use MIGRATE_RESERVE rather than fail an allocation. goto - * is used because __rmqueue_smallest is an inline function - * and we want just one call site - */ - if (!page) { - migratetype = MIGRATE_RESERVE; - goto retry_reserve; + /* + * Use MIGRATE_RESERVE rather than fail an allocation. + * goto is used because __rmqueue_smallest is an inline + * function and we want just one call site + */ + if (!page) { + migratetype = MIGRATE_RESERVE; + goto retry; + } } } -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weijie Yang Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 16 Oct 2014 13:13:57 +0800 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org On Thu, Oct 16, 2014 at 11:35 AM, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. I'm not very clear to this description, what issue do you try to solve? Make MIGRATE_CMA be the fallback of desired MIGRATE_UNMOVABLE? > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. I don't think so. That will cause MIGRATE_CMA depleted prematurely, and when a user(such as camera) wants CMA memory, he will not get the wanted memory. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. I don't think this is the root cause of oom. But I am interested in the CMA shrinker idea, I will follow this mail. Thanks for your work, add some test data will be better. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Thu, 16 Oct 2014 10:45:21 +0200 Message-ID: <1471435.6q4YYkTopF@vostro.rjw.lan> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: Hui Zhu Cc: m.szyprowski@samsung.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org [CC list trimmed] On Thursday, October 16, 2014 11:35:49 AM Hui Zhu wrote: > Function shrink_all_memory try to free `nr_to_reclaim' of memory. > CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of > memory. It need different scan_control with current caller function > hibernate_preallocate_memory. > > If hibernation is true, the caller is hibernate_preallocate_memory. > if not, the caller is CMA alloc function. > > Signed-off-by: Hui Zhu > --- > include/linux/swap.h | 3 ++- > kernel/power/snapshot.c | 2 +- > mm/vmscan.c | 19 +++++++++++++------ > 3 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/include/linux/swap.h b/include/linux/swap.h > index 37a585b..9f2cb43 100644 > --- a/include/linux/swap.h > +++ b/include/linux/swap.h > @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, > gfp_t gfp_mask, bool noswap, > struct zone *zone, > unsigned long *nr_scanned); > -extern unsigned long shrink_all_memory(unsigned long nr_pages); > +extern unsigned long shrink_all_memory(unsigned long nr_pages, > + bool hibernation); > extern int vm_swappiness; > extern int remove_mapping(struct address_space *mapping, struct page *page); > extern unsigned long vm_total_pages; > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c > index 791a618..a00fc35 100644 > --- a/kernel/power/snapshot.c > +++ b/kernel/power/snapshot.c > @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) > * NOTE: If this is not done, performance will be hurt badly in some > * test cases. > */ > - shrink_all_memory(saveable - size); > + shrink_all_memory(saveable - size, true); Instead of doing this, can you please define __shrink_all_memory() that will take the appropriate struct scan_control as an argument and then define two wrappers around that, one for hibernation and one for CMA? The way you did it opens a field for bugs caused by passing a wrong value as the second argument. > > /* > * The number of saveable pages in memory was too high, so apply some > diff --git a/mm/vmscan.c b/mm/vmscan.c > index dcb4707..fdcfa30 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) > wake_up_interruptible(&pgdat->kswapd_wait); > } > > -#ifdef CONFIG_HIBERNATION > +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE > /* > * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of > * freed pages. > @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) > * LRU order by reclaiming preferentially > * inactive > active > active referenced > active mapped > */ > -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) > +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) > { > struct reclaim_state reclaim_state; > struct scan_control sc = { > .nr_to_reclaim = nr_to_reclaim, > - .gfp_mask = GFP_HIGHUSER_MOVABLE, > .priority = DEF_PRIORITY, > - .may_writepage = 1, > .may_unmap = 1, > .may_swap = 1, > - .hibernation_mode = 1, > }; > struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); > struct task_struct *p = current; > unsigned long nr_reclaimed; > > + if (hibernation) { > + sc.hibernation_mode = 1; > + sc.may_writepage = 1; > + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; > + } else { > + sc.hibernation_mode = 0; > + sc.may_writepage = !laptop_mode; > + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; > + } > + > p->flags |= PF_MEMALLOC; > lockdep_set_current_reclaim_state(sc.gfp_mask); > reclaim_state.reclaimed_slab = 0; > @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) > > return nr_reclaimed; > } > -#endif /* CONFIG_HIBERNATION */ > +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ > > /* It's optimal to keep kswapds on the same CPUs as their memory, but > not required for correctness. So if the last cpu in a node goes > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laura Abbott Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 16 Oct 2014 01:55:46 -0700 Message-ID: <543F8812.2020002@codeaurora.org> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org On 10/15/2014 8:35 PM, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. > > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > 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. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Fri, 17 Oct 2014 06:18:39 +0000 Message-ID: <70d41b6fdea74d5fb88f314708879acc@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> <1471435.6q4YYkTopF@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Return-path: Received: from [42.62.48.242] ([42.62.48.242]:7204 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750729AbaJQGSz (ORCPT ); Fri, 17 Oct 2014 02:18:55 -0400 Content-Language: zh-CN Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: "Rafael J. Wysocki" Cc: "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" CgpPbiAxMC8xNi8xNCAxNjoyOSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gW0NDIGxpc3Qg dHJpbW1lZF0KPgo+IE9uIFRodXJzZGF5LCBPY3RvYmVyIDE2LCAyMDE0IDExOjM1OjQ5IEFNIEh1 aSBaaHUgd3JvdGU6Cj4+IEZ1bmN0aW9uIHNocmlua19hbGxfbWVtb3J5IHRyeSB0byBmcmVlIGBu cl90b19yZWNsYWltJyBvZiBtZW1vcnkuCj4+IENNQV9BR0dSRVNTSVZFX1NIUklOSyBmdW5jdGlv biB3aWxsIGNhbGwgdGhpcyBmdW5jdG9uIHRvIGZyZWUgYG5yX3RvX3JlY2xhaW0nIG9mCj4+IG1l bW9yeS4gIEl0IG5lZWQgZGlmZmVyZW50IHNjYW5fY29udHJvbCB3aXRoIGN1cnJlbnQgY2FsbGVy IGZ1bmN0aW9uCj4+IGhpYmVybmF0ZV9wcmVhbGxvY2F0ZV9tZW1vcnkuCj4+Cj4+IElmIGhpYmVy bmF0aW9uIGlzIHRydWUsIHRoZSBjYWxsZXIgaXMgaGliZXJuYXRlX3ByZWFsbG9jYXRlX21lbW9y eS4KPj4gaWYgbm90LCB0aGUgY2FsbGVyIGlzIENNQSBhbGxvYyBmdW5jdGlvbi4KPj4KPj4gU2ln bmVkLW9mZi1ieTogSHVpIFpodSA8emh1aHVpQHhpYW9taS5jb20+Cj4+IC0tLQo+PiAgIGluY2x1 ZGUvbGludXgvc3dhcC5oICAgIHwgIDMgKystCj4+ICAga2VybmVsL3Bvd2VyL3NuYXBzaG90LmMg fCAgMiArLQo+PiAgIG1tL3Ztc2Nhbi5jICAgICAgICAgICAgIHwgMTkgKysrKysrKysrKysrKy0t LS0tLQo+PiAgIDMgZmlsZXMgY2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMo LSkKPj4KPj4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvc3dhcC5oIGIvaW5jbHVkZS9saW51 eC9zd2FwLmgKPj4gaW5kZXggMzdhNTg1Yi4uOWYyY2I0MyAxMDA2NDQKPj4gLS0tIGEvaW5jbHVk ZS9saW51eC9zd2FwLmgKPj4gKysrIGIvaW5jbHVkZS9saW51eC9zd2FwLmgKPj4gQEAgLTMzNSw3 ICszMzUsOCBAQCBleHRlcm4gdW5zaWduZWQgbG9uZyBtZW1fY2dyb3VwX3Nocmlua19ub2RlX3pv bmUoc3RydWN0IG1lbV9jZ3JvdXAgKm1lbSwKPj4gICAJCQkJCQlnZnBfdCBnZnBfbWFzaywgYm9v bCBub3N3YXAsCj4+ICAgCQkJCQkJc3RydWN0IHpvbmUgKnpvbmUsCj4+ICAgCQkJCQkJdW5zaWdu ZWQgbG9uZyAqbnJfc2Nhbm5lZCk7Cj4+IC1leHRlcm4gdW5zaWduZWQgbG9uZyBzaHJpbmtfYWxs X21lbW9yeSh1bnNpZ25lZCBsb25nIG5yX3BhZ2VzKTsKPj4gK2V4dGVybiB1bnNpZ25lZCBsb25n IHNocmlua19hbGxfbWVtb3J5KHVuc2lnbmVkIGxvbmcgbnJfcGFnZXMsCj4+ICsJCQkJICAgICAg IGJvb2wgaGliZXJuYXRpb24pOwo+PiAgIGV4dGVybiBpbnQgdm1fc3dhcHBpbmVzczsKPj4gICBl eHRlcm4gaW50IHJlbW92ZV9tYXBwaW5nKHN0cnVjdCBhZGRyZXNzX3NwYWNlICptYXBwaW5nLCBz dHJ1Y3QgcGFnZSAqcGFnZSk7Cj4+ICAgZXh0ZXJuIHVuc2lnbmVkIGxvbmcgdm1fdG90YWxfcGFn ZXM7Cj4+IGRpZmYgLS1naXQgYS9rZXJuZWwvcG93ZXIvc25hcHNob3QuYyBiL2tlcm5lbC9wb3dl ci9zbmFwc2hvdC5jCj4+IGluZGV4IDc5MWE2MTguLmEwMGZjMzUgMTAwNjQ0Cj4+IC0tLSBhL2tl cm5lbC9wb3dlci9zbmFwc2hvdC5jCj4+ICsrKyBiL2tlcm5lbC9wb3dlci9zbmFwc2hvdC5jCj4+ IEBAIC0xNjU3LDcgKzE2NTcsNyBAQCBpbnQgaGliZXJuYXRlX3ByZWFsbG9jYXRlX21lbW9yeSh2 b2lkKQo+PiAgIAkgKiBOT1RFOiBJZiB0aGlzIGlzIG5vdCBkb25lLCBwZXJmb3JtYW5jZSB3aWxs IGJlIGh1cnQgYmFkbHkgaW4gc29tZQo+PiAgIAkgKiB0ZXN0IGNhc2VzLgo+PiAgIAkgKi8KPj4g LQlzaHJpbmtfYWxsX21lbW9yeShzYXZlYWJsZSAtIHNpemUpOwo+PiArCXNocmlua19hbGxfbWVt b3J5KHNhdmVhYmxlIC0gc2l6ZSwgdHJ1ZSk7Cj4KPiBJbnN0ZWFkIG9mIGRvaW5nIHRoaXMsIGNh biB5b3UgcGxlYXNlIGRlZmluZQo+Cj4gX19zaHJpbmtfYWxsX21lbW9yeSgpCj4KPiB0aGF0IHdp bGwgdGFrZSB0aGUgYXBwcm9wcmlhdGUgc3RydWN0IHNjYW5fY29udHJvbCBhcyBhbiBhcmd1bWVu dCBhbmQKPiB0aGVuIGRlZmluZSB0d28gd3JhcHBlcnMgYXJvdW5kIHRoYXQsIG9uZSBmb3IgaGli ZXJuYXRpb24gYW5kIG9uZSBmb3IgQ01BPwo+Cj4gVGhlIHdheSB5b3UgZGlkIGl0IG9wZW5zIGEg ZmllbGQgZm9yIGJ1Z3MgY2F1c2VkIGJ5IHBhc3NpbmcgYSB3cm9uZyB2YWx1ZQo+IGFzIHRoZSBz ZWNvbmQgYXJndW1lbnQuCgpUaGFua3MgUmFmYWVsLgpJIHdpbGwgdXBkYXRlIHBhdGNoIGFjY29y ZGluZyB0byB5b3VyIGNvbW1lbnRzLgoKQmVzdCwKSHVpCgo+Cj4+Cj4+ICAgCS8qCj4+ICAgCSAq IFRoZSBudW1iZXIgb2Ygc2F2ZWFibGUgcGFnZXMgaW4gbWVtb3J5IHdhcyB0b28gaGlnaCwgc28g YXBwbHkgc29tZQo+PiBkaWZmIC0tZ2l0IGEvbW0vdm1zY2FuLmMgYi9tbS92bXNjYW4uYwo+PiBp bmRleCBkY2I0NzA3Li5mZGNmYTMwIDEwMDY0NAo+PiAtLS0gYS9tbS92bXNjYW4uYwo+PiArKysg Yi9tbS92bXNjYW4uYwo+PiBAQCAtMzQwNCw3ICszNDA0LDcgQEAgdm9pZCB3YWtldXBfa3N3YXBk KHN0cnVjdCB6b25lICp6b25lLCBpbnQgb3JkZXIsIGVudW0gem9uZV90eXBlIGNsYXNzem9uZV9p ZHgpCj4+ICAgCXdha2VfdXBfaW50ZXJydXB0aWJsZSgmcGdkYXQtPmtzd2FwZF93YWl0KTsKPj4g ICB9Cj4+Cj4+IC0jaWZkZWYgQ09ORklHX0hJQkVSTkFUSU9OCj4+ICsjaWYgZGVmaW5lZCBDT05G SUdfSElCRVJOQVRJT04gfHwgZGVmaW5lZCBDT05GSUdfQ01BX0FHR1JFU1NJVkUKPj4gICAvKgo+ PiAgICAqIFRyeSB0byBmcmVlIGBucl90b19yZWNsYWltJyBvZiBtZW1vcnksIHN5c3RlbS13aWRl LCBhbmQgcmV0dXJuIHRoZSBudW1iZXIgb2YKPj4gICAgKiBmcmVlZCBwYWdlcy4KPj4gQEAgLTM0 MTMsMjIgKzM0MTMsMjkgQEAgdm9pZCB3YWtldXBfa3N3YXBkKHN0cnVjdCB6b25lICp6b25lLCBp bnQgb3JkZXIsIGVudW0gem9uZV90eXBlIGNsYXNzem9uZV9pZHgpCj4+ICAgICogTFJVIG9yZGVy IGJ5IHJlY2xhaW1pbmcgcHJlZmVyZW50aWFsbHkKPj4gICAgKiBpbmFjdGl2ZSA+IGFjdGl2ZSA+ IGFjdGl2ZSByZWZlcmVuY2VkID4gYWN0aXZlIG1hcHBlZAo+PiAgICAqLwo+PiAtdW5zaWduZWQg bG9uZyBzaHJpbmtfYWxsX21lbW9yeSh1bnNpZ25lZCBsb25nIG5yX3RvX3JlY2xhaW0pCj4+ICt1 bnNpZ25lZCBsb25nIHNocmlua19hbGxfbWVtb3J5KHVuc2lnbmVkIGxvbmcgbnJfdG9fcmVjbGFp bSwgYm9vbCBoaWJlcm5hdGlvbikKPj4gICB7Cj4+ICAgCXN0cnVjdCByZWNsYWltX3N0YXRlIHJl Y2xhaW1fc3RhdGU7Cj4+ICAgCXN0cnVjdCBzY2FuX2NvbnRyb2wgc2MgPSB7Cj4+ICAgCQkubnJf dG9fcmVjbGFpbSA9IG5yX3RvX3JlY2xhaW0sCj4+IC0JCS5nZnBfbWFzayA9IEdGUF9ISUdIVVNF Ul9NT1ZBQkxFLAo+PiAgIAkJLnByaW9yaXR5ID0gREVGX1BSSU9SSVRZLAo+PiAtCQkubWF5X3dy aXRlcGFnZSA9IDEsCj4+ICAgCQkubWF5X3VubWFwID0gMSwKPj4gICAJCS5tYXlfc3dhcCA9IDEs Cj4+IC0JCS5oaWJlcm5hdGlvbl9tb2RlID0gMSwKPj4gICAJfTsKPj4gICAJc3RydWN0IHpvbmVs aXN0ICp6b25lbGlzdCA9IG5vZGVfem9uZWxpc3QobnVtYV9ub2RlX2lkKCksIHNjLmdmcF9tYXNr KTsKPj4gICAJc3RydWN0IHRhc2tfc3RydWN0ICpwID0gY3VycmVudDsKPj4gICAJdW5zaWduZWQg bG9uZyBucl9yZWNsYWltZWQ7Cj4+Cj4+ICsJaWYgKGhpYmVybmF0aW9uKSB7Cj4+ICsJCXNjLmhp YmVybmF0aW9uX21vZGUgPSAxOwo+PiArCQlzYy5tYXlfd3JpdGVwYWdlID0gMTsKPj4gKwkJc2Mu Z2ZwX21hc2sgPSBHRlBfSElHSFVTRVJfTU9WQUJMRTsKPj4gKwl9IGVsc2Ugewo+PiArCQlzYy5o aWJlcm5hdGlvbl9tb2RlID0gMDsKPj4gKwkJc2MubWF5X3dyaXRlcGFnZSA9ICFsYXB0b3BfbW9k ZTsKPj4gKwkJc2MuZ2ZwX21hc2sgPSBHRlBfVVNFUiB8IF9fR0ZQX01PVkFCTEUgfCBfX0dGUF9I SUdITUVNOwo+PiArCX0KPj4gKwo+PiAgIAlwLT5mbGFncyB8PSBQRl9NRU1BTExPQzsKPj4gICAJ bG9ja2RlcF9zZXRfY3VycmVudF9yZWNsYWltX3N0YXRlKHNjLmdmcF9tYXNrKTsKPj4gICAJcmVj bGFpbV9zdGF0ZS5yZWNsYWltZWRfc2xhYiA9IDA7Cj4+IEBAIC0zNDQyLDcgKzM0NDksNyBAQCB1 bnNpZ25lZCBsb25nIHNocmlua19hbGxfbWVtb3J5KHVuc2lnbmVkIGxvbmcgbnJfdG9fcmVjbGFp bSkKPj4KPj4gICAJcmV0dXJuIG5yX3JlY2xhaW1lZDsKPj4gICB9Cj4+IC0jZW5kaWYgLyogQ09O RklHX0hJQkVSTkFUSU9OICovCj4+ICsjZW5kaWYgLyogQ09ORklHX0hJQkVSTkFUSU9OIHx8IENP TkZJR19DTUFfQUdHUkVTU0lWRSAqLwo+Pgo+PiAgIC8qIEl0J3Mgb3B0aW1hbCB0byBrZWVwIGtz d2FwZHMgb24gdGhlIHNhbWUgQ1BVcyBhcyB0aGVpciBtZW1vcnksIGJ1dAo+PiAgICAgIG5vdCBy ZXF1aXJlZCBmb3IgY29ycmVjdG5lc3MuICBTbyBpZiB0aGUgbGFzdCBjcHUgaW4gYSBub2RlIGdv ZXMKPj4KPgo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Fri, 17 Oct 2014 07:44:26 +0000 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Return-path: Received: from [42.62.48.242] ([42.62.48.242]:63453 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751403AbaJQHpU (ORCPT ); Fri, 17 Oct 2014 03:45:20 -0400 Content-Language: zh-CN Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Laura Abbott , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" Cc: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" CgpPbiAxMC8xNi8xNCAxNjo1NiwgTGF1cmEgQWJib3R0IHdyb3RlOgo+IE9uIDEwLzE1LzIwMTQg ODozNSBQTSwgSHVpIFpodSB3cm90ZToKPj4gSW4gZmFsbGJhY2tzIG9mIHBhZ2VfYWxsb2MuYywg TUlHUkFURV9DTUEgaXMgdGhlIGZhbGxiYWNrIG9mCj4+IE1JR1JBVEVfTU9WQUJMRS4KPj4gTUlH UkFURV9NT1ZBQkxFIHdpbGwgdXNlIE1JR1JBVEVfQ01BIHdoZW4gaXQgZG9lc24ndCBoYXZlIGEg cGFnZSBpbgo+PiBvcmRlciB0aGF0IExpbnV4IGtlcm5lbCB3YW50Lgo+Pgo+PiBJZiBhIHN5c3Rl bSB0aGF0IGhhcyBhIGxvdCBvZiB1c2VyIHNwYWNlIHByb2dyYW0gaXMgcnVubmluZywgZm9yCj4+ IGluc3RhbmNlLCBhbiBBbmRyb2lkIGJvYXJkLCBtb3N0IG9mIG1lbW9yeSBpcyBpbiBNSUdSQVRF X01PVkFCTEUgYW5kCj4+IGFsbG9jYXRlZC4gIEJlZm9yZSBmdW5jdGlvbiBfX3JtcXVldWVfZmFs bGJhY2sgZ2V0IG1lbW9yeSBmcm9tCj4+IE1JR1JBVEVfQ01BLCB0aGUgb29tX2tpbGxlciB3aWxs IGtpbGwgYSB0YXNrIHRvIHJlbGVhc2UgbWVtb3J5IHdoZW4KPj4ga2VybmVsIHdhbnQgZ2V0IE1J R1JBVEVfVU5NT1ZBQkxFIG1lbW9yeSBiZWNhdXNlIGZhbGxiYWNrcyBvZgo+PiBNSUdSQVRFX1VO TU9WQUJMRSBhcmUgTUlHUkFURV9SRUNMQUlNQUJMRSBhbmQgTUlHUkFURV9NT1ZBQkxFLgo+PiBU aGlzIHN0YXR1cyBpcyBvZGQuICBUaGUgTUlHUkFURV9DTUEgaGFzIGEgbG90IGZyZWUgbWVtb3J5 IGJ1dCBMaW51eAo+PiBrZXJuZWwga2lsbCBzb21lIHRhc2tzIHRvIHJlbGVhc2UgbWVtb3J5Lgo+ Pgo+PiBUaGlzIHBhdGNoIHNlcmllcyBhZGRzIGEgbmV3IGZ1bmN0aW9uIENNQV9BR0dSRVNTSVZF IHRvIG1ha2UgQ01BIG1lbW9yeQo+PiBiZSBtb3JlIGFnZ3Jlc3NpdmUgYWJvdXQgYWxsb2NhdGlv bi4KPj4gSWYgZnVuY3Rpb24gQ01BX0FHR1JFU1NJVkUgaXMgYXZhaWxhYmxlLCB3aGVuIExpbnV4 IGtlcm5lbCBjYWxsIGZ1bmN0aW9uCj4+IF9fcm1xdWV1ZSB0cnkgdG8gZ2V0IHBhZ2VzIGZyb20g TUlHUkFURV9NT1ZBQkxFIGFuZCBjb25kaXRpb25zIGFsbG93LAo+PiBNSUdSQVRFX0NNQSB3aWxs IGJlIGFsbG9jYXRlZCBhcyBNSUdSQVRFX01PVkFCTEUgZmlyc3QuICBJZiBNSUdSQVRFX0NNQQo+ PiBkb2Vzbid0IGhhdmUgZW5vdWdoIHBhZ2VzIGZvciBhbGxvY2F0aW9uLCBnbyBiYWNrIHRvIGFs bG9jYXRlIG1lbW9yeSBmcm9tCj4+IE1JR1JBVEVfTU9WQUJMRS4KPj4gVGhlbiB0aGUgbWVtb3J5 IG9mIE1JR1JBVEVfTU9WQUJMRSBjYW4gYmUga2VwdCBmb3IgTUlHUkFURV9VTk1PVkFCTEUgYW5k Cj4+IE1JR1JBVEVfUkVDTEFJTUFCTEUgd2hpY2ggZG9lc24ndCBoYXZlIGZhbGxiYWNrIE1JR1JB VEVfQ01BLgo+Pgo+Cj4gSXQncyBnb29kIHRvIHNlZSBhbm90aGVyIHByb3Bvc2FsIHRvIGZpeCBD TUEgdXRpbGl6YXRpb24uCgpUaGFua3MgTGF1cmEuCgpEbyB5b3UgaGF2ZQo+IGFueSBkYXRhIGFi b3V0IHRoZSBzdWNjZXNzIHJhdGUgb2YgQ01BIGNvbnRpZ3VvdXMgYWxsb2NhdGlvbiBhZnRlcgo+ IHRoaXMgcGF0Y2ggc2VyaWVzPyAgIEkgcGxheWVkIGFyb3VuZCB3aXRoIGEgc2ltaWxhciBhcHBy b2FjaCBvZiB1c2luZwo+IENNQSBmb3IgTUlHUkFURV9NT1ZBQkxFIGFsbG9jYXRpb25zIGFuZCBm b3VuZCB0aGF0IGFsdGhvdWdoIHV0aWxpemF0aW9uCj4gZGlkIGluY3JlYXNlLCBjb250aWd1b3Vz IGFsbG9jYXRpb25zIGZhaWxlZCBhdCBhIGhpZ2hlciByYXRlIGFuZCB3ZXJlCj4gbXVjaCBzbG93 ZXIuIEkgc2VlIHdoYXQgdGhpcyBzZXJpZXMgaXMgdHJ5aW5nIHRvIGRvIHdpdGggYXZvaWRpbmcK PiBhbGxvY2F0aW9uIGZyb20gQ01BIHBhZ2VzIHdoZW4gYSBjb250aWd1b3VzIGFsbG9jYXRpb24g aXMgcHJvZ3Jlc3MuCj4gTXkgY29uY2VybiBpcyB0aGF0IHRoZXJlIHdvdWxkIHN0aWxsIGJlIHBy b2JsZW1zIHdpdGggY29udGlndW91cwo+IGFsbG9jYXRpb24gYWZ0ZXIgYWxsIHRoZSBNSUdSQVRF X01PVkFCTEUgZmFsbGJhY2sgaGFzIGhhcHBlbmVkLgoKSSBkaWQgc29tZSB0ZXN0IHdpdGggdGhl IGNtYV9hbGxvY19jb3VudGVyIGFuZCBjbWEtYWdncmVzc2l2ZS1zaHJpbmsgaW4gCmEgYW5kcm9p ZCBib2FyZCB0aGF0IGhhcyAxZyBtZW1vcnkuICBSdW4gc29tZSBhcHBzIHRvIG1ha2UgZnJlZSBD TUEgCmNsb3NlIHRvIHRoZSB2YWx1ZSBvZiBjbWFfYWdncmVzc2l2ZV9mcmVlX21pbig1MDAgcGFn ZXMpLiAgQSBkcml2ZXIgCkJlZ2luIHRvIHJlcXVlc3QgQ01BIG1vcmUgdGhhbiAxMCB0aW1lcy4g RWFjaCB0aW1lLCBpdCB3aWxsIHJlcXVlc3QgbW9yZSAKdGhhbiAzMDAwIHBhZ2VzLgoKSSBkb24n dCBoYXZlIGVzdGFibGlzaGVkIG51bWJlciBmb3IgdGhhdCBiZWNhdXNlIGl0IGlzIHJlYWxseSBo YXJkIHRvIApnZXQgYSBmYWlsLiAgSSB0aGluayB0aGUgc3VjY2VzcyByYXRlIGlzIG92ZXIgOTUl IGF0IGxlYXN0LgoKQW5kIEkgdGhpbmsgbWF5YmUgdGhlIGlzb2xhdGUgZmFpbCBoYXMgcmVsYXRp b24gd2l0aCBwYWdlIGFsbG9jIGFuZCBmcmVlIApjb2RlLiAgTWF5YmUgbGV0IHpvbmUtPmxvY2sg cHJvdGVjdCBtb3JlIGNvZGUgY2FuIGhhbmRsZSB0aGlzIGlzc3VlLgoKVGhhbmtzLApIdWkKCj4K PiBUaGFua3MsCj4gTGF1cmEKPgo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma Date: Fri, 17 Oct 2014 17:28:04 +0800 Message-ID: <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> References: <1471435.6q4YYkTopF@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [42.62.48.242] ([42.62.48.242]:4613 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751459AbaJQJ2t (ORCPT ); Fri, 17 Oct 2014 05:28:49 -0400 In-Reply-To: <1471435.6q4YYkTopF@vostro.rjw.lan> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Update this patch according to the comments from Rafael. Function shrink_all_memory_for_cma try to free `nr_to_reclaim' of memory. CMA aggressive shrink function will call this functon to free `nr_to_reclaim' of memory. Signed-off-by: Hui Zhu --- mm/vmscan.c | 58 +++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..658dc8d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,6 +3404,28 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE +static unsigned long __shrink_all_memory(struct scan_control *sc) +{ + struct reclaim_state reclaim_state; + struct zonelist *zonelist = node_zonelist(numa_node_id(), sc->gfp_mask); + struct task_struct *p = current; + unsigned long nr_reclaimed; + + p->flags |= PF_MEMALLOC; + lockdep_set_current_reclaim_state(sc->gfp_mask); + reclaim_state.reclaimed_slab = 0; + p->reclaim_state = &reclaim_state; + + nr_reclaimed = do_try_to_free_pages(zonelist, sc); + + p->reclaim_state = NULL; + lockdep_clear_current_reclaim_state(); + p->flags &= ~PF_MEMALLOC; + + return nr_reclaimed; +} + #ifdef CONFIG_HIBERNATION /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of @@ -3415,7 +3437,6 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) */ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) { - struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, .gfp_mask = GFP_HIGHUSER_MOVABLE, @@ -3425,24 +3446,31 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) .may_swap = 1, .hibernation_mode = 1, }; - struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); - struct task_struct *p = current; - unsigned long nr_reclaimed; - - p->flags |= PF_MEMALLOC; - lockdep_set_current_reclaim_state(sc.gfp_mask); - reclaim_state.reclaimed_slab = 0; - p->reclaim_state = &reclaim_state; - nr_reclaimed = do_try_to_free_pages(zonelist, &sc); + return __shrink_all_memory(&sc); +} +#endif /* CONFIG_HIBERNATION */ - p->reclaim_state = NULL; - lockdep_clear_current_reclaim_state(); - p->flags &= ~PF_MEMALLOC; +#ifdef CONFIG_CMA_AGGRESSIVE +/* + * Try to free `nr_to_reclaim' of memory, system-wide, for CMA aggressive + * shrink function. + */ +void shrink_all_memory_for_cma(unsigned long nr_to_reclaim) +{ + struct scan_control sc = { + .nr_to_reclaim = nr_to_reclaim, + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM, + .priority = DEF_PRIORITY, + .may_writepage = !laptop_mode, + .may_unmap = 1, + .may_swap = 1, + }; - return nr_reclaimed; + __shrink_all_memory(&sc); } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_CMA_AGGRESSIVE */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: [PATCH v2 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Date: Fri, 17 Oct 2014 17:30:05 +0800 Message-ID: <1413538205-15915-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [42.62.48.242] ([42.62.48.242]:51003 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750828AbaJQJaN (ORCPT ); Fri, 17 Oct 2014 05:30:13 -0400 In-Reply-To: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Update this patch according to the comments from Rafael. Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and cma_aggressive_shrink_switch. cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be controlled by sysctl vm.cma-aggressive-switch. cma_aggressive_free_min can be controlled by sysctl "vm.cma-aggressive-free-min". If the number of CMA free pages is small than this sysctl value, CMA_AGGRESSIVE will not work in page alloc code. cma_aggressive_shrink_switch can be controlled by sysctl "vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal memory's size is smaller than the size that it want to allocate, do memory shrink with function git commit -a --amend before driver allocate pages from CMA. When Linux kernel try to reserve custom contiguous area, increase the value of cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code. After reserve custom contiguous area function return, decreases the value of cma_alloc_counter. Signed-off-by: Hui Zhu --- include/linux/cma.h | 7 +++++++ kernel/sysctl.c | 27 +++++++++++++++++++++++++++ mm/cma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) diff --git a/include/linux/cma.h b/include/linux/cma.h index 0430ed0..df96abf 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -15,6 +15,13 @@ struct cma; +#ifdef CONFIG_CMA_AGGRESSIVE +extern atomic_t cma_alloc_counter; +extern int cma_aggressive_switch; +extern unsigned long cma_aggressive_free_min; +extern int cma_aggressive_shrink_switch; +#endif + extern phys_addr_t cma_get_base(struct cma *cma); extern unsigned long cma_get_size(struct cma *cma); diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 4aada6d..646929e2 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -92,6 +92,10 @@ #include #endif +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + #if defined(CONFIG_SYSCTL) @@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_CMA_AGGRESSIVE + { + .procname = "cma-aggressive-switch", + .data = &cma_aggressive_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, + { + .procname = "cma-aggressive-free-min", + .data = &cma_aggressive_free_min, + .maxlen = sizeof(unsigned long), + .mode = 0600, + .proc_handler = proc_doulongvec_minmax, + }, + { + .procname = "cma-aggressive-shrink-switch", + .data = &cma_aggressive_shrink_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, +#endif { } }; diff --git a/mm/cma.c b/mm/cma.c index 963bc4a..1cf341c 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -33,6 +33,7 @@ #include #include #include +#include struct cma { unsigned long base_pfn; @@ -127,6 +128,27 @@ err: return -EINVAL; } +#ifdef CONFIG_CMA_AGGRESSIVE +/* The counter for the dma_alloc_from_contiguous and + dma_release_from_contiguous. */ +atomic_t cma_alloc_counter = ATOMIC_INIT(0); + +/* Swich of CMA_AGGRESSIVE. */ +int cma_aggressive_switch __read_mostly; + +/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE will + not work. */ +#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN +unsigned long cma_aggressive_free_min __read_mostly = + CONFIG_CMA_AGGRESSIVE_FREE_MIN; +#else +unsigned long cma_aggressive_free_min __read_mostly = 500; +#endif + +/* Swich of CMA_AGGRESSIVE shink. */ +int cma_aggressive_shrink_switch __read_mostly; +#endif + static int __init cma_init_reserved_areas(void) { int i; @@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void) return ret; } +#ifdef CONFIG_CMA_AGGRESSIVE + cma_aggressive_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX + if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX) +#else + if (memblock_phys_mem_size() <= 0x40000000) +#endif + cma_aggressive_switch = 1; + + cma_aggressive_shrink_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK + if (cma_aggressive_switch) + cma_aggressive_shrink_switch = 1; +#endif +#endif + return 0; } core_initcall(cma_init_reserved_areas); @@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) unsigned long bitmap_maxno, bitmap_no, bitmap_count; struct page *page = NULL; int ret; +#ifdef CONFIG_CMA_AGGRESSIVE + int free = global_page_state(NR_FREE_PAGES) + - global_page_state(NR_FREE_CMA_PAGES) + - totalreserve_pages; +#endif if (!cma || !cma->count) return NULL; @@ -326,6 +369,13 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) bitmap_maxno = cma_bitmap_maxno(cma); bitmap_count = cma_bitmap_pages_to_bits(cma, count); +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_inc(&cma_alloc_counter); + if (cma_aggressive_switch && cma_aggressive_shrink_switch + && free < count) + shrink_all_memory_for_cma(count - free); +#endif + for (;;) { mutex_lock(&cma->lock); bitmap_no = bitmap_find_next_zero_area(cma->bitmap, @@ -361,6 +411,10 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) start = bitmap_no + mask + 1; } +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_dec(&cma_alloc_counter); +#endif + pr_debug("%s(): returned %p\n", __func__, page); return page; } -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: PINTU KUMAR Subject: Re: [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma Date: Fri, 17 Oct 2014 21:50:08 -0700 Message-ID: <1413607808.82877.YahooMailNeo@web160105.mail.bf1.yahoo.com> References: <1471435.6q4YYkTopF@vostro.rjw.lan> <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> Reply-To: PINTU KUMAR Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: Hui Zhu , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" Cc: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "pintu_agarwal@yahoo.com" , "pintu.k@samsung.com" List-Id: linux-pm@vger.kernel.org Hi,=0A=0A=0A=0A----- Original Message -----=0A> From: Hui Zhu =0A> To: rjw@rjwysocki.net; len.brown@intel.com; pavel@ucw.cz; m.szyp= rowski@samsung.com; akpm@linux-foundation.org; mina86@mina86.com; aneesh.ku= mar@linux.vnet.ibm.com; iamjoonsoo.kim@lge.com; hannes@cmpxchg.org; riel@re= dhat.com; mgorman@suse.de; minchan@kernel.org; nasa4836@gmail.com; ddstreet= @ieee.org; hughd@google.com; mingo@kernel.org; rientjes@google.com; peterz@= infradead.org; keescook@chromium.org; atomlin@redhat.com; raistlin@linux.it= ; axboe@fb.com; paulmck@linux.vnet.ibm.com; kirill.shutemov@linux.intel.com= ; n-horiguchi@ah.jp.nec.com; k.khlebnikov@samsung.com; msalter@redhat.com; = deller@gmx.de; tangchen@cn.fujitsu.com; ben@decadent.org.uk; akinobu.mita@g= mail.com; lauraa@codeaurora.org; vbabka@suse.cz; sasha.levin@oracle.com; vd= avydov@parallels.com; suleiman@google.com=0A> Cc: linux-kernel@vger.kernel.= org; linux-pm@vger.kernel.org; linux-mm@kvack.org; Hui Zhu =0A> Sent: Friday, 17 October 2014 2:58 PM=0A> Subject: [PATCH v2 2/4] (= CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma=0A> =0A> Update = this patch according to the comments from Rafael.=0A> =0A> Function shrink_= all_memory_for_cma try to free `nr_to_reclaim' of memory.=0A> CMA aggressiv= e shrink function will call this functon to free =0A> `nr_to_reclaim' of=0A= > memory.=0A=0AInstead, we can have in short shrink_cma_memory(nr_to_reclai= m).=0ASometime back I already proposed to have shrink_memory for CMA here:= =0Ahttp://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/14310= 3.html=0A=0ANow, I am working on another solution that uses shrink_all_memo= ry().=0AThis can be helpful even for non CMA cases as well to bring back th= e higher-order pages quickly.=0AWill post the patches until next week.=0A= =0A=0A> =0A> Signed-off-by: Hui Zhu =0A> ---=0A> mm/vmsc= an.c | 58 +++++++++++++++++++++++++++++++++++++++++++---------------=0A> 1 = file changed, 43 insertions(+), 15 deletions(-)=0A> =0A> diff --git a/mm/vm= scan.c b/mm/vmscan.c=0A> index dcb4707..658dc8d 100644=0A> --- a/mm/vmscan.= c=0A> +++ b/mm/vmscan.c=0A> @@ -3404,6 +3404,28 @@ void wakeup_kswapd(struc= t zone *zone, int order, enum =0A> zone_type classzone_idx)=0A> wake_up= _interruptible(&pgdat->kswapd_wait);=0A> }=0A> =0A> +#if defined CONFIG_HIB= ERNATION || defined CONFIG_CMA_AGGRESSIVE=0A> +static unsigned long __shrin= k_all_memory(struct scan_control *sc)=0A> +{=0A> + struct reclaim_state = reclaim_state;=0A> + struct zonelist *zonelist =3D node_zonelist(numa_no= de_id(), sc->gfp_mask);=0A> + struct task_struct *p =3D current;=0A> + = unsigned long nr_reclaimed;=0A> +=0A> + p->flags |=3D PF_MEMALLOC;=0A>= + lockdep_set_current_reclaim_state(sc->gfp_mask);=0A> + reclaim_sta= te.reclaimed_slab =3D 0;=0A> + p->reclaim_state =3D &reclaim_state;=0A> = +=0A> + nr_reclaimed =3D do_try_to_free_pages(zonelist, sc);=0A> +=0A> += p->reclaim_state =3D NULL;=0A> + lockdep_clear_current_reclaim_state= ();=0A> + p->flags &=3D ~PF_MEMALLOC;=0A> +=0A> + return nr_reclaimed= ;=0A> +}=0A> +=0A> #ifdef CONFIG_HIBERNATION=0A> /*=0A> * Try to free `nr= _to_reclaim' of memory, system-wide, and return the =0A> number of=0A> @@ -= 3415,7 +3437,6 @@ void wakeup_kswapd(struct zone *zone, int order, enum =0A= > zone_type classzone_idx)=0A> */=0A> unsigned long shrink_all_memory(uns= igned long nr_to_reclaim)=0A> {=0A> - struct reclaim_state reclaim_state= ;=0A> struct scan_control sc =3D {=0A> .nr_to_reclaim =3D nr_to= _reclaim,=0A> .gfp_mask =3D GFP_HIGHUSER_MOVABLE,=0A> @@ -3425,24 += 3446,31 @@ unsigned long shrink_all_memory(unsigned long =0A> nr_to_reclaim= )=0A> .may_swap =3D 1,=0A> .hibernation_mode =3D 1,=0A> = };=0A> - struct zonelist *zonelist =3D node_zonelist(numa_node_id(), sc= .gfp_mask);=0A> - struct task_struct *p =3D current;=0A> - unsigned l= ong nr_reclaimed;=0A> -=0A> - p->flags |=3D PF_MEMALLOC;=0A> - lockde= p_set_current_reclaim_state(sc.gfp_mask);=0A> - reclaim_state.reclaimed_= slab =3D 0;=0A> - p->reclaim_state =3D &reclaim_state;=0A> =0A> - nr_= reclaimed =3D do_try_to_free_pages(zonelist, &sc);=0A> + return __shrink= _all_memory(&sc);=0A> +}=0A> +#endif /* CONFIG_HIBERNATION */=0A> =0A> - = p->reclaim_state =3D NULL;=0A> - lockdep_clear_current_reclaim_state();= =0A> - p->flags &=3D ~PF_MEMALLOC;=0A> +#ifdef CONFIG_CMA_AGGRESSIVE=0A>= +/*=0A> + * Try to free `nr_to_reclaim' of memory, system-wide, for CMA ag= gressive=0A> + * shrink function.=0A> + */=0A> +void shrink_all_memory_for_= cma(unsigned long nr_to_reclaim)=0A> +{=0A> + struct scan_control sc =3D= {=0A> + .nr_to_reclaim =3D nr_to_reclaim,=0A> + .gfp_mask = =3D GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM,=0A> + .priority =3D DE= F_PRIORITY,=0A> + .may_writepage =3D !laptop_mode,=0A> + .may= _unmap =3D 1,=0A> + .may_swap =3D 1,=0A> + };=0A> =0A> - retur= n nr_reclaimed;=0A> + __shrink_all_memory(&sc);=0A> }=0A> -#endif /* CON= FIG_HIBERNATION */=0A> +#endif /* CONFIG_CMA_AGGRESSIVE */=0A> +#endif /* C= ONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */=0A> =0A> /* It's optimal to k= eep kswapds on the same CPUs as their memory, but=0A> not required for = correctness. So if the last cpu in a node goes=0A> -- =0A> 1.9.1=0A> =0A> = =0A> --=0A> To unsubscribe, send a message with 'unsubscribe linux-mm' in= =0A> the body to majordomo@kvack.org. For more info on Linux MM,=0A> see: = http://www.linux-mm.org/ .=0A> Don't email: =0A> email@kvack.org =0A> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Date: Sun, 19 Oct 2014 00:15:25 +0200 Message-ID: <20141018221525.GB10843@amd> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:33776 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751518AbaJRWP1 (ORCPT ); Sat, 18 Oct 2014 18:15:27 -0400 Content-Disposition: inline In-Reply-To: <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Hi! > Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. > Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK > that depend on CMA_AGGRESSIVE. > > If physical memory size (not include CMA memory) in byte less than or equal to > CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) > will be opened. Ok... Do I understand it correctly that there is some problem with hibernation not working on machines not working on machines with big CMA areas...? But adding 4 config options end-user has no chance to set right can not be the best solution, can it? > +config CMA_AGGRESSIVE_PHY_MAX > + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" > + depends on CMA_AGGRESSIVE > + default 0x40000000 > + help > + If physical memory size (not include CMA memory) in byte less than or > + equal to this value, CMA aggressive switch will be opened. > + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control > + the CMA AGGRESSIVE switch. For example... how am I expected to figure right value to place here? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Date: Wed, 22 Oct 2014 05:44:24 +0000 Message-ID: <2c27ad87839b42ca85c03c9541550d30@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> <201410220126.s9M1Qita026502@spam.xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Return-path: Content-Language: zh-CN Sender: owner-linux-mm@kvack.org To: Pavel Machek Cc: "rjw@rjwysocki.net" , "len.brown@intel.com" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , raistlin@linux.it List-Id: linux-pm@vger.kernel.org CgpPbiAxMC8yMi8xNCAwOToyNywgUGF2ZWwgTWFjaGVrIHdyb3RlOgo+IEhpIQo+Cj4+IEFkZCBD TUFfQUdHUkVTU0lWRSBjb25maWcgdGhhdCBkZXBlbmQgb24gQ01BIHRvIExpbnV4IGtlcm5lbCBj b25maWcuCj4+IEFkZCBDTUFfQUdHUkVTU0lWRV9QSFlfTUFYLCBDTUFfQUdHUkVTU0lWRV9GUkVF X01JTiBhbmQgQ01BX0FHR1JFU1NJVkVfU0hSSU5LCj4+IHRoYXQgZGVwZW5kIG9uIENNQV9BR0dS RVNTSVZFLgo+Pgo+PiBJZiBwaHlzaWNhbCBtZW1vcnkgc2l6ZSAobm90IGluY2x1ZGUgQ01BIG1l bW9yeSkgaW4gYnl0ZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG8KPj4gQ01BX0FHR1JFU1NJVkVfUEhZ X01BWCwgQ01BIGFnZ3Jlc3NpdmUgc3dpdGNoIChzeXNjdGwgdm0uY21hLWFnZ3Jlc3NpdmUtc3dp dGNoKQo+PiB3aWxsIGJlIG9wZW5lZC4KPgo+IE9rLi4uCj4KPiBEbyBJIHVuZGVyc3RhbmQgaXQg Y29ycmVjdGx5IHRoYXQgdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdpdGgKPiBoaWJlcm5hdGlvbiBu b3Qgd29ya2luZyBvbiBtYWNoaW5lcyBub3Qgd29ya2luZyBvbiBtYWNoaW5lcyB3aXRoIGJpZwo+ IENNQSBhcmVhcy4uLj8KCk5vLCB0aGVzZSBwYXRjaGVzIHdhbnQgdG8gaGFuZGxlIHRoaXMgaXNz dWUgdGhhdCBtb3N0IG9mIENNQSBtZW1vcnkgaXMgCm5vdCBhbGxvY2F0ZWQgYmVmb3JlIGxvd21l bW9yeWtpbGxlciBvciBvb21fa2lsbGVyIGJlZ2luIHRvIGtpbGwgdGFza3MuCgo+Cj4gQnV0IGFk ZGluZyA0IGNvbmZpZyBvcHRpb25zIGVuZC11c2VyIGhhcyBubyBjaGFuY2UgdG8gc2V0IHJpZ2h0 IGNhbgo+IG5vdCBiZSB0aGUgYmVzdCBzb2x1dGlvbiwgY2FuIGl0Pwo+Cj4+ICtjb25maWcgQ01B X0FHR1JFU1NJVkVfUEhZX01BWAo+PiArCWhleCAiUGh5c2ljYWwgbWVtb3J5IHNpemUgaW4gQnl0 ZXMgdGhhdCBhdXRvIHR1cm4gb24gdGhlIENNQSBhZ2dyZXNzaXZlIHN3aXRjaCIKPj4gKwlkZXBl bmRzIG9uIENNQV9BR0dSRVNTSVZFCj4+ICsJZGVmYXVsdCAweDQwMDAwMDAwCj4+ICsJaGVscAo+ PiArCSAgSWYgcGh5c2ljYWwgbWVtb3J5IHNpemUgKG5vdCBpbmNsdWRlIENNQSBtZW1vcnkpIGlu IGJ5dGUgbGVzcyB0aGFuIG9yCj4+ICsJICBlcXVhbCB0byB0aGlzIHZhbHVlLCBDTUEgYWdncmVz c2l2ZSBzd2l0Y2ggd2lsbCBiZSBvcGVuZWQuCj4+ICsJICBBZnRlciB0aGUgTGludXggYm9vdCwg c3lzY3RsICJ2bS5jbWEtYWdncmVzc2l2ZS1zd2l0Y2giIGNhbiBjb250cm9sCj4+ICsJICB0aGUg Q01BIEFHR1JFU1NJVkUgc3dpdGNoLgo+Cj4gRm9yIGV4YW1wbGUuLi4gaG93IGFtIEkgZXhwZWN0 ZWQgdG8gZmlndXJlIHJpZ2h0IHZhbHVlIHRvIHBsYWNlIGhlcmU/CgpJIGFncmVlIHdpdGggdGhh dC4gIEkgd2lsbCB1cGRhdGUgdGhpcyBjb25maWcgdG8gYXV0byBzZXQgaW4gbmV4dCB2ZXJzaW9u LgoKVGhhbmtzLApIdWkKCj4KPiAJCQkJCQkJCQlQYXZlbAo+Cg== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Hurley Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Wed, 22 Oct 2014 08:01:54 -0400 Message-ID: <54479CB2.5040408@hurleysoftware.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <543F8812.2020002@codeaurora.org> Sender: owner-linux-mm@kvack.org To: Laura Abbott , Hui Zhu , m.szyprowski@samsung.com, akpm@linux-foundation.org, riel@redhat.com, mgorman@suse.de, hughd@google.com, akinobu.mita@gmail.com Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org On 10/16/2014 04:55 AM, Laura Abbott wrote: > On 10/15/2014 8:35 PM, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. >> > > 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. What impact does this series have on x86 platforms now that CMA is the backup allocator for all iommu dma allocations? Regards, Peter Hurley -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 23 Oct 2014 00:40:57 +0000 Message-ID: <04a07ed889c840f1919e220f906af3af@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <54479CB2.5040408@hurleysoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Return-path: Received: from [42.62.48.242] ([42.62.48.242]:29681 "EHLO outbound.mxmail.xiaomi.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754359AbaJWAlO (ORCPT ); Wed, 22 Oct 2014 20:41:14 -0400 Content-Language: zh-CN Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Peter Hurley , Laura Abbott , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "riel@redhat.com" , "mgorman@suse.de" , "hughd@google.com" , "akinobu.mita@gmail.com" Cc: "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , n-hor CgpPbiAxMC8yMi8xNCAyMDowMiwgUGV0ZXIgSHVybGV5IHdyb3RlOgo+IE9uIDEwLzE2LzIwMTQg MDQ6NTUgQU0sIExhdXJhIEFiYm90dCB3cm90ZToKPj4gT24gMTAvMTUvMjAxNCA4OjM1IFBNLCBI dWkgWmh1IHdyb3RlOgo+Pj4gSW4gZmFsbGJhY2tzIG9mIHBhZ2VfYWxsb2MuYywgTUlHUkFURV9D TUEgaXMgdGhlIGZhbGxiYWNrIG9mCj4+PiBNSUdSQVRFX01PVkFCTEUuCj4+PiBNSUdSQVRFX01P VkFCTEUgd2lsbCB1c2UgTUlHUkFURV9DTUEgd2hlbiBpdCBkb2Vzbid0IGhhdmUgYSBwYWdlIGlu Cj4+PiBvcmRlciB0aGF0IExpbnV4IGtlcm5lbCB3YW50Lgo+Pj4KPj4+IElmIGEgc3lzdGVtIHRo YXQgaGFzIGEgbG90IG9mIHVzZXIgc3BhY2UgcHJvZ3JhbSBpcyBydW5uaW5nLCBmb3IKPj4+IGlu c3RhbmNlLCBhbiBBbmRyb2lkIGJvYXJkLCBtb3N0IG9mIG1lbW9yeSBpcyBpbiBNSUdSQVRFX01P VkFCTEUgYW5kCj4+PiBhbGxvY2F0ZWQuICBCZWZvcmUgZnVuY3Rpb24gX19ybXF1ZXVlX2ZhbGxi YWNrIGdldCBtZW1vcnkgZnJvbQo+Pj4gTUlHUkFURV9DTUEsIHRoZSBvb21fa2lsbGVyIHdpbGwg a2lsbCBhIHRhc2sgdG8gcmVsZWFzZSBtZW1vcnkgd2hlbgo+Pj4ga2VybmVsIHdhbnQgZ2V0IE1J R1JBVEVfVU5NT1ZBQkxFIG1lbW9yeSBiZWNhdXNlIGZhbGxiYWNrcyBvZgo+Pj4gTUlHUkFURV9V Tk1PVkFCTEUgYXJlIE1JR1JBVEVfUkVDTEFJTUFCTEUgYW5kIE1JR1JBVEVfTU9WQUJMRS4KPj4+ IFRoaXMgc3RhdHVzIGlzIG9kZC4gIFRoZSBNSUdSQVRFX0NNQSBoYXMgYSBsb3QgZnJlZSBtZW1v cnkgYnV0IExpbnV4Cj4+PiBrZXJuZWwga2lsbCBzb21lIHRhc2tzIHRvIHJlbGVhc2UgbWVtb3J5 Lgo+Pj4KPj4+IFRoaXMgcGF0Y2ggc2VyaWVzIGFkZHMgYSBuZXcgZnVuY3Rpb24gQ01BX0FHR1JF U1NJVkUgdG8gbWFrZSBDTUEgbWVtb3J5Cj4+PiBiZSBtb3JlIGFnZ3Jlc3NpdmUgYWJvdXQgYWxs b2NhdGlvbi4KPj4+IElmIGZ1bmN0aW9uIENNQV9BR0dSRVNTSVZFIGlzIGF2YWlsYWJsZSwgd2hl biBMaW51eCBrZXJuZWwgY2FsbCBmdW5jdGlvbgo+Pj4gX19ybXF1ZXVlIHRyeSB0byBnZXQgcGFn ZXMgZnJvbSBNSUdSQVRFX01PVkFCTEUgYW5kIGNvbmRpdGlvbnMgYWxsb3csCj4+PiBNSUdSQVRF X0NNQSB3aWxsIGJlIGFsbG9jYXRlZCBhcyBNSUdSQVRFX01PVkFCTEUgZmlyc3QuICBJZiBNSUdS QVRFX0NNQQo+Pj4gZG9lc24ndCBoYXZlIGVub3VnaCBwYWdlcyBmb3IgYWxsb2NhdGlvbiwgZ28g YmFjayB0byBhbGxvY2F0ZSBtZW1vcnkgZnJvbQo+Pj4gTUlHUkFURV9NT1ZBQkxFLgo+Pj4gVGhl biB0aGUgbWVtb3J5IG9mIE1JR1JBVEVfTU9WQUJMRSBjYW4gYmUga2VwdCBmb3IgTUlHUkFURV9V Tk1PVkFCTEUgYW5kCj4+PiBNSUdSQVRFX1JFQ0xBSU1BQkxFIHdoaWNoIGRvZXNuJ3QgaGF2ZSBm YWxsYmFjayBNSUdSQVRFX0NNQS4KPj4+Cj4+Cj4+IEl0J3MgZ29vZCB0byBzZWUgYW5vdGhlciBw cm9wb3NhbCB0byBmaXggQ01BIHV0aWxpemF0aW9uLiBEbyB5b3UgaGF2ZQo+PiBhbnkgZGF0YSBh Ym91dCB0aGUgc3VjY2VzcyByYXRlIG9mIENNQSBjb250aWd1b3VzIGFsbG9jYXRpb24gYWZ0ZXIK Pj4gdGhpcyBwYXRjaCBzZXJpZXM/IEkgcGxheWVkIGFyb3VuZCB3aXRoIGEgc2ltaWxhciBhcHBy b2FjaCBvZiB1c2luZwo+PiBDTUEgZm9yIE1JR1JBVEVfTU9WQUJMRSBhbGxvY2F0aW9ucyBhbmQg Zm91bmQgdGhhdCBhbHRob3VnaCB1dGlsaXphdGlvbgo+PiBkaWQgaW5jcmVhc2UsIGNvbnRpZ3Vv dXMgYWxsb2NhdGlvbnMgZmFpbGVkIGF0IGEgaGlnaGVyIHJhdGUgYW5kIHdlcmUKPj4gbXVjaCBz bG93ZXIuIEkgc2VlIHdoYXQgdGhpcyBzZXJpZXMgaXMgdHJ5aW5nIHRvIGRvIHdpdGggYXZvaWRp bmcKPj4gYWxsb2NhdGlvbiBmcm9tIENNQSBwYWdlcyB3aGVuIGEgY29udGlndW91cyBhbGxvY2F0 aW9uIGlzIHByb2dyZXNzLgo+PiBNeSBjb25jZXJuIGlzIHRoYXQgdGhlcmUgd291bGQgc3RpbGwg YmUgcHJvYmxlbXMgd2l0aCBjb250aWd1b3VzCj4+IGFsbG9jYXRpb24gYWZ0ZXIgYWxsIHRoZSBN SUdSQVRFX01PVkFCTEUgZmFsbGJhY2sgaGFzIGhhcHBlbmVkLgo+Cj4gV2hhdCBpbXBhY3QgZG9l cyB0aGlzIHNlcmllcyBoYXZlIG9uIHg4NiBwbGF0Zm9ybXMgbm93IHRoYXQgQ01BIGlzIHRoZQo+ IGJhY2t1cCBhbGxvY2F0b3IgZm9yIGFsbCBpb21tdSBkbWEgYWxsb2NhdGlvbnM/CgpUaGV5IHdp bGwgbm90IGFmZmVjdCBkcml2ZXIgQ01BIG1lbW9yeSBhbGxvY2F0aW9uLgoKVGhhbmtzLApIdWkK Cj4KPiBSZWdhcmRzLAo+IFBldGVyIEh1cmxleQo+Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Fri, 24 Oct 2014 14:25:53 +0900 Message-ID: <20141024052553.GE15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:46155 "EHLO lgemrelse7q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524AbaJXFYu (ORCPT ); Fri, 24 Oct 2014 01:24:50 -0400 Content-Disposition: inline In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. > > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. Hello, I did some work similar to this. Please reference following links. https://lkml.org/lkml/2014/5/28/64 https://lkml.org/lkml/2014/5/28/57 And, aggressive allocation should be postponed until freepage counting bug is fixed, because aggressive allocation enlarge the possiblity of problem occurence. I tried to fix that bug, too. See following link. https://lkml.org/lkml/2014/10/23/90 Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonsoo Kim Subject: Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Date: Fri, 24 Oct 2014 14:28:50 +0900 Message-ID: <20141024052849.GF15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote: > If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and > conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) > allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. > > Signed-off-by: Hui Zhu > --- > mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- > 1 file changed, 31 insertions(+), 11 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 736d8e1..87bc326 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -65,6 +65,10 @@ > #include > #include "internal.h" > > +#ifdef CONFIG_CMA_AGGRESSIVE > +#include > +#endif > + > /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ > static DEFINE_MUTEX(pcp_batch_high_lock); > #define MIN_PERCPU_PAGELIST_FRACTION (8) > @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, > { > struct page *page; > > -retry_reserve: > +#ifdef CONFIG_CMA_AGGRESSIVE > + if (cma_aggressive_switch > + && migratetype == MIGRATE_MOVABLE > + && atomic_read(&cma_alloc_counter) == 0 > + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min > + + (1 << order)) > + migratetype = MIGRATE_CMA; > +#endif > +retry: I don't get it why cma_alloc_counter should be tested. When cma alloc is progress, pageblock is isolated so that pages on that pageblock cannot be allocated. Why should we prevent aggressive allocation in this case? Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Wed, 29 Oct 2014 15:43:33 +0100 Message-ID: <5450FD15.4000708@suse.cz> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from cantor2.suse.de ([195.135.220.15]:44851 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932962AbaJ2Onm (ORCPT ); Wed, 29 Oct 2014 10:43:42 -0400 In-Reply-To: <543F8812.2020002@codeaurora.org> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org 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 - it's more complex, but I guess we have most of the necessary infrastructure in compaction already :) Thoughts? Vlastimil > Thanks, > Laura > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Mon, 3 Nov 2014 15:28:38 +0800 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <20141024052553.GE15243@js1304-P5Q-DELUXE> Sender: owner-linux-mm@kvack.org To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-ker List-Id: linux-pm@vger.kernel.org On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > Hello, > > I did some work similar to this. > Please reference following links. > > https://lkml.org/lkml/2014/5/28/64 > https://lkml.org/lkml/2014/5/28/57 > I tested #1 approach and found the problem. Although free memory on > meminfo can move around low watermark, there is large fluctuation on free > memory, because too many pages are reclaimed when kswapd is invoked. > Reason for this behaviour is that successive allocated CMA pages are > on the LRU list in that order and kswapd reclaim them in same order. > These memory doesn't help watermark checking from kwapd, so too many > pages are reclaimed, I guess. This issue can be handle with some change around shrink code. I am trying to integrate a patch for them. But I am not sure we met the same issue. Do you mind give me more info about this part? > > And, aggressive allocation should be postponed until freepage counting > bug is fixed, because aggressive allocation enlarge the possiblity > of problem occurence. I tried to fix that bug, too. See following link. > > https://lkml.org/lkml/2014/10/23/90 I am following these patches. They are great! Thanks for your work. Best, Hui > > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Mon, 3 Nov 2014 17:05:46 +0900 Message-ID: <20141103080546.GB7052@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:48125 "EHLO lgemrelse6q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbaKCIEM (ORCPT ); Mon, 3 Nov 2014 03:04:12 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > >> MIGRATE_MOVABLE. > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > >> order that Linux kernel want. > >> > >> If a system that has a lot of user space program is running, for > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > >> allocated. Before function __rmqueue_fallback get memory from > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > >> kernel kill some tasks to release memory. > >> > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > >> be more aggressive about allocation. > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > >> doesn't have enough pages for allocation, go back to allocate memory from > >> MIGRATE_MOVABLE. > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > Hello, > > > > I did some work similar to this. > > Please reference following links. > > > > https://lkml.org/lkml/2014/5/28/64 > > https://lkml.org/lkml/2014/5/28/57 > > > I tested #1 approach and found the problem. Although free memory on > > meminfo can move around low watermark, there is large fluctuation on free > > memory, because too many pages are reclaimed when kswapd is invoked. > > Reason for this behaviour is that successive allocated CMA pages are > > on the LRU list in that order and kswapd reclaim them in same order. > > These memory doesn't help watermark checking from kwapd, so too many > > pages are reclaimed, I guess. > > This issue can be handle with some change around shrink code. I am > trying to integrate a patch for them. > But I am not sure we met the same issue. Do you mind give me more > info about this part? I forgot the issue because there is so big time-gap. I need sometime to bring issue back to my brain. I will answer it soon after some thinking. > > > > > And, aggressive allocation should be postponed until freepage counting > > bug is fixed, because aggressive allocation enlarge the possiblity > > of problem occurence. I tried to fix that bug, too. See following link. > > > > https://lkml.org/lkml/2014/10/23/90 > > I am following these patches. They are great! Thanks for your work. Thanks. :) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Mon, 3 Nov 2014 16:46:23 +0800 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <5450FD15.4000708@suse.cz> Sender: owner-linux-mm@kvack.org To: Vlastimil Babka , iamjoonsoo.kim@lge.com Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kern List-Id: linux-pm@vger.kernel.org On Wed, Oct 29, 2014 at 10:43 PM, 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 > - it's more complex, but I guess we have most of the necessary > infrastructure in compaction already :) I think this idea make CMA allocation part become complex but make balance and shrink code become easy because it make CMA become real memory. I just worry about the speed of migrate memory with this idea. :) Thanks, Hui > > Thoughts? > Vlastimil > >> Thanks, >> Laura >> > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Tue, 4 Nov 2014 11:31:12 +0900 Message-ID: <20141104023112.GA17804@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> <20141103080546.GB7052@js1304-P5Q-DELUXE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20141103080546.GB7052@js1304-P5Q-DELUXE> Sender: owner-linux-mm@kvack.org To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger. List-Id: linux-pm@vger.kernel.org On Mon, Nov 03, 2014 at 05:05:46PM +0900, Joonsoo Kim wrote: > On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > > >> MIGRATE_MOVABLE. > > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > > >> order that Linux kernel want. > > >> > > >> If a system that has a lot of user space program is running, for > > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > > >> allocated. Before function __rmqueue_fallback get memory from > > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > > >> kernel kill some tasks to release memory. > > >> > > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > > >> be more aggressive about allocation. > > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > > >> doesn't have enough pages for allocation, go back to allocate memory from > > >> MIGRATE_MOVABLE. > > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > > > Hello, > > > > > > I did some work similar to this. > > > Please reference following links. > > > > > > https://lkml.org/lkml/2014/5/28/64 > > > https://lkml.org/lkml/2014/5/28/57 > > > > > I tested #1 approach and found the problem. Although free memory on > > > meminfo can move around low watermark, there is large fluctuation on free > > > memory, because too many pages are reclaimed when kswapd is invoked. > > > Reason for this behaviour is that successive allocated CMA pages are > > > on the LRU list in that order and kswapd reclaim them in same order. > > > These memory doesn't help watermark checking from kwapd, so too many > > > pages are reclaimed, I guess. > > > > This issue can be handle with some change around shrink code. I am > > trying to integrate a patch for them. > > But I am not sure we met the same issue. Do you mind give me more > > info about this part? > > I forgot the issue because there is so big time-gap. I need sometime > to bring issue back to my brain. I will answer it soon after some thinking. Hello, Yes, the issue I mentioned before can be handled by modifying shrink code. I didn't dive into the problem so I also didn't know the detail. What I know is that there is large fluctuation on memory statistics and my guess is that it is caused by order of reclaimable pages. If we use #1 approach, the bulk of cma pages used for page cache or something are linked together and will be reclaimed all at once, because reclaiming cma pages are not counted and watermark check still fails until normal pages are reclaimed. I think that round-robin approach is better. Reasons are on the following: 1) Want to spread CMA freepages to whole users, not specific one user. We can modify shirnk code not to reclaim pages on CMA, because it doesn't help watermark checking in some cases. In this case, if we don't use round-robin, one specific user whose mapping with CMA pages can get all the benefit. Others would take all the overhead. I think that spreading will make all users fair. 2) Using CMA freepages first needlessly imposes overhead to CMA user. If the system has enough normal freepages, it is better not to use it as much as possible. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Minchan Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Tue, 4 Nov 2014 16:53:30 +0900 Message-ID: <20141104075330.GB23102@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <5450FD15.4000708@suse.cz> Sender: owner-linux-mm@kvack.org To: Vlastimil Babka Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org 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@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Tue, 4 Nov 2014 16:59:24 +0800 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <20141104075330.GB23102@bbox> Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: Vlastimil Babka , Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.c List-Id: linux-pm@vger.kernel.org On Tue, Nov 4, 2014 at 3:53 PM, Minchan Kim wrote: > 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. Thanks. > > 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. Even if kernel use it to allocate the CMA memory, CMA alloc latency will happen if most of memory is allocated and driver try to get CMA memory. https://lkml.org/lkml/2014/10/17/129 https://lkml.org/lkml/2014/10/17/130 These patches let cma_alloc do a shrink with function shrink_all_memory_for_cma if need. It handle a lot of latency issue in my part. And I think it can be more configurable for example some device use it and others not. Thanks, Hui > >> >> Thoughts? >> Vlastimil >> >> >Thanks, >> >Laura >> > >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email@kvack.org > > -- > Kind regards, > Minchan Kim > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Tue, 04 Nov 2014 10:29:59 +0100 Message-ID: <54589C97.4060309@suse.cz> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141104075330.GB23102@bbox> Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org On 11/04/2014 08:53 AM, Minchan Kim wrote: > Hello, > > On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: >> On 10/16/2014 10:55 AM, Laura Abbott wrote: >> >> 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. Well, if it relaims CMA pages, then it has to be followed by the migration. Is that better or worse than breaking LRU assumptions by reclaiming based on where the page is located? I thought this was basically what lumpy reclaim did, and it was removed. > 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. Yeah that would be great. > 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 I'm not sure I understand enough from this. You want to introduce a movable zone instead of CMA pageblocks? But how to size it, resize it, would it be possible? > 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. Why would it overlap in the first place? Just because it wouldn't be sized on pageblock boundary? Or to make (re)sizing simpler? Yeah we could probably handle that, but it's not completely for free (you iterate over blocks/pages uselessly). > 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. Yeah maybe it could be simpler in the end. Although a new zone type could be a disturbing change, with some overhead to per-cpu structures etc. The allocations in that zone would be somewhat at disadvantage wrt LRU, as CMA allocation would mostly reclaim them instead of migrating away (assuming there wouldn't be so much spare space for migration as when CMA pageblocks are part of a much larger zone). But I guess the same could be said about the DMA zone... >> >> Thoughts? >> Vlastimil >> >>> Thanks, >>> Laura >>> >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Minchan Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Fri, 7 Nov 2014 16:06:55 +0900 Message-ID: <20141107070655.GA3486@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> <54589C97.4060309@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <54589C97.4060309@suse.cz> Sender: owner-linux-mm@kvack.org To: Vlastimil Babka Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org List-Id: linux-pm@vger.kernel.org Hello, On Tue, Nov 04, 2014 at 10:29:59AM +0100, Vlastimil Babka wrote: > On 11/04/2014 08:53 AM, Minchan Kim wrote: > >Hello, > > > >On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: > >>On 10/16/2014 10:55 AM, Laura Abbott wrote: > >> > >>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. > > Well, if it relaims CMA pages, then it has to be followed by the > migration. Is that better or worse than breaking LRU assumptions by > reclaiming based on where the page is located? I thought this was > basically what lumpy reclaim did, and it was removed. It would work and it might cost for using for CMA because CMA already can migrate/discard lots of pages, which will hurt LRU assumption. However, I don't think it's optimal. > > >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. > > Yeah that would be great. > > >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 > > I'm not sure I understand enough from this. You want to introduce a > movable zone instead of CMA pageblocks? But how to size it, resize > it, would it be possible? Why do we need to care of resizing? All of CMA pages are reserved by using memblock during boot. If we can set the zone size after that, maybe we don't need to resize the zone. > > >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. > > Why would it overlap in the first place? Just because it wouldn't be > sized on pageblock boundary? Or to make (re)sizing simpler? Yeah we > could probably handle that, but it's not completely for free (you > iterate over blocks/pages uselessly). Reserved pages for CMA are spread over the system memory. So zones could overlap each other so we need check that overlapping like pageblock_pfn_to_page while we need to walk pfn in order. It's not free but it would add the overhead pfn-order walking like compaction, which is not hot path. > > >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. > > Yeah maybe it could be simpler in the end. Although a new zone type > could be a disturbing change, with some overhead to per-cpu > structures etc. The allocations in that zone would be somewhat at > disadvantage wrt LRU, as CMA allocation would mostly reclaim them > instead of migrating away (assuming there wouldn't be so much spare > space for migration as when CMA pageblocks are part of a much larger > zone). But I guess the same could be said about the DMA zone... What do you mean "CMA allocation"? If you meant movable pages allocation like userspace page, it would be round-robin by fair zone policy. If you meant device request for contiguous memory allocation so we should reclaim CMA pages due to lack of spare memory, we don't have no choice. IOW, it's trade-off for using CMA. > > >> > >>Thoughts? > >>Vlastimil > >> > >>>Thanks, > >>>Laura > >>> > >> > >>-- > >>To unsubscribe, send a message with 'unsubscribe linux-mm' in > >>the body to majordomo@kvack.org. For more info on Linux MM, > >>see: http://www.linux-mm.org/ . > >>Don't email: email@kvack.org > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hui Zhu Subject: Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Date: Fri, 28 Nov 2014 11:45:04 +0800 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> <20141024052849.GF15243@js1304-P5Q-DELUXE> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-oi0-f46.google.com ([209.85.218.46]:63884 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbaK1Dpp (ORCPT ); Thu, 27 Nov 2014 22:45:45 -0500 In-Reply-To: <20141024052849.GF15243@js1304-P5Q-DELUXE> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger On Fri, Oct 24, 2014 at 1:28 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote: >> If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and >> conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) >> allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. >> >> Signed-off-by: Hui Zhu >> --- >> mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- >> 1 file changed, 31 insertions(+), 11 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 736d8e1..87bc326 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -65,6 +65,10 @@ >> #include >> #include "internal.h" >> >> +#ifdef CONFIG_CMA_AGGRESSIVE >> +#include >> +#endif >> + >> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ >> static DEFINE_MUTEX(pcp_batch_high_lock); >> #define MIN_PERCPU_PAGELIST_FRACTION (8) >> @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, >> { >> struct page *page; >> >> -retry_reserve: >> +#ifdef CONFIG_CMA_AGGRESSIVE >> + if (cma_aggressive_switch >> + && migratetype == MIGRATE_MOVABLE >> + && atomic_read(&cma_alloc_counter) == 0 >> + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min >> + + (1 << order)) >> + migratetype = MIGRATE_CMA; >> +#endif >> +retry: > > I don't get it why cma_alloc_counter should be tested. > When cma alloc is progress, pageblock is isolated so that pages on that > pageblock cannot be allocated. Why should we prevent aggressive > allocation in this case? > Hi Joonsoo, Even if the pageblock is isolated in the begin of function alloc_contig_range, it will unisolate if alloc_contig_range get some error for example "PFNs busy". And the cma_alloc will keep call alloc_contig_range with another address if need. So it will decrease the contradiction between CMA allocation in cma_alloc and __rmqueue with cma_alloc_counter. Thanks, Hui > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id A89146B006E for ; Wed, 15 Oct 2014 23:36:19 -0400 (EDT) Received: by mail-pd0-f175.google.com with SMTP id v10so2436039pde.20 for ; Wed, 15 Oct 2014 20:36:19 -0700 (PDT) Received: from manager.mioffice.cn ([42.62.48.242]) by mx.google.com with ESMTP id rf9si17524319pbc.221.2014.10.15.20.36.17 for ; Wed, 15 Oct 2014 20:36:18 -0700 (PDT) From: Hui Zhu Subject: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Thu, 16 Oct 2014 11:35:49 +0800 Message-ID: <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Function shrink_all_memory try to free `nr_to_reclaim' of memory. CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of memory. It need different scan_control with current caller function hibernate_preallocate_memory. If hibernation is true, the caller is hibernate_preallocate_memory. if not, the caller is CMA alloc function. Signed-off-by: Hui Zhu --- include/linux/swap.h | 3 ++- kernel/power/snapshot.c | 2 +- mm/vmscan.c | 19 +++++++++++++------ 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/include/linux/swap.h b/include/linux/swap.h index 37a585b..9f2cb43 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, gfp_t gfp_mask, bool noswap, struct zone *zone, unsigned long *nr_scanned); -extern unsigned long shrink_all_memory(unsigned long nr_pages); +extern unsigned long shrink_all_memory(unsigned long nr_pages, + bool hibernation); extern int vm_swappiness; extern int remove_mapping(struct address_space *mapping, struct page *page); extern unsigned long vm_total_pages; diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 791a618..a00fc35 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) * NOTE: If this is not done, performance will be hurt badly in some * test cases. */ - shrink_all_memory(saveable - size); + shrink_all_memory(saveable - size, true); /* * The number of saveable pages in memory was too high, so apply some diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..fdcfa30 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } -#ifdef CONFIG_HIBERNATION +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of * freed pages. @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) * LRU order by reclaiming preferentially * inactive > active > active referenced > active mapped */ -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) { struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, - .gfp_mask = GFP_HIGHUSER_MOVABLE, .priority = DEF_PRIORITY, - .may_writepage = 1, .may_unmap = 1, .may_swap = 1, - .hibernation_mode = 1, }; struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); struct task_struct *p = current; unsigned long nr_reclaimed; + if (hibernation) { + sc.hibernation_mode = 1; + sc.may_writepage = 1; + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; + } else { + sc.hibernation_mode = 0; + sc.may_writepage = !laptop_mode; + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; + } + p->flags |= PF_MEMALLOC; lockdep_set_current_reclaim_state(sc.gfp_mask); reclaim_state.reclaimed_slab = 0; @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) return nr_reclaimed; } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by kanga.kvack.org (Postfix) with ESMTP id BF6EA6B0069 for ; Fri, 17 Oct 2014 03:45:21 -0400 (EDT) Received: by mail-pd0-f170.google.com with SMTP id p10so330807pdj.29 for ; Fri, 17 Oct 2014 00:45:21 -0700 (PDT) Received: from manager.mioffice.cn ([42.62.48.242]) by mx.google.com with ESMTP id on3si552009pbc.29.2014.10.17.00.45.18 for ; Fri, 17 Oct 2014 00:45:20 -0700 (PDT) From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Fri, 17 Oct 2014 07:44:26 +0000 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> Content-Language: zh-CN Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "akinobu.mita@gmail.com" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" Cc: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" CgpPbiAxMC8xNi8xNCAxNjo1NiwgTGF1cmEgQWJib3R0IHdyb3RlOgo+IE9uIDEwLzE1LzIwMTQg ODozNSBQTSwgSHVpIFpodSB3cm90ZToKPj4gSW4gZmFsbGJhY2tzIG9mIHBhZ2VfYWxsb2MuYywg TUlHUkFURV9DTUEgaXMgdGhlIGZhbGxiYWNrIG9mCj4+IE1JR1JBVEVfTU9WQUJMRS4KPj4gTUlH UkFURV9NT1ZBQkxFIHdpbGwgdXNlIE1JR1JBVEVfQ01BIHdoZW4gaXQgZG9lc24ndCBoYXZlIGEg cGFnZSBpbgo+PiBvcmRlciB0aGF0IExpbnV4IGtlcm5lbCB3YW50Lgo+Pgo+PiBJZiBhIHN5c3Rl bSB0aGF0IGhhcyBhIGxvdCBvZiB1c2VyIHNwYWNlIHByb2dyYW0gaXMgcnVubmluZywgZm9yCj4+ IGluc3RhbmNlLCBhbiBBbmRyb2lkIGJvYXJkLCBtb3N0IG9mIG1lbW9yeSBpcyBpbiBNSUdSQVRF X01PVkFCTEUgYW5kCj4+IGFsbG9jYXRlZC4gIEJlZm9yZSBmdW5jdGlvbiBfX3JtcXVldWVfZmFs bGJhY2sgZ2V0IG1lbW9yeSBmcm9tCj4+IE1JR1JBVEVfQ01BLCB0aGUgb29tX2tpbGxlciB3aWxs IGtpbGwgYSB0YXNrIHRvIHJlbGVhc2UgbWVtb3J5IHdoZW4KPj4ga2VybmVsIHdhbnQgZ2V0IE1J R1JBVEVfVU5NT1ZBQkxFIG1lbW9yeSBiZWNhdXNlIGZhbGxiYWNrcyBvZgo+PiBNSUdSQVRFX1VO TU9WQUJMRSBhcmUgTUlHUkFURV9SRUNMQUlNQUJMRSBhbmQgTUlHUkFURV9NT1ZBQkxFLgo+PiBU aGlzIHN0YXR1cyBpcyBvZGQuICBUaGUgTUlHUkFURV9DTUEgaGFzIGEgbG90IGZyZWUgbWVtb3J5 IGJ1dCBMaW51eAo+PiBrZXJuZWwga2lsbCBzb21lIHRhc2tzIHRvIHJlbGVhc2UgbWVtb3J5Lgo+ Pgo+PiBUaGlzIHBhdGNoIHNlcmllcyBhZGRzIGEgbmV3IGZ1bmN0aW9uIENNQV9BR0dSRVNTSVZF IHRvIG1ha2UgQ01BIG1lbW9yeQo+PiBiZSBtb3JlIGFnZ3Jlc3NpdmUgYWJvdXQgYWxsb2NhdGlv bi4KPj4gSWYgZnVuY3Rpb24gQ01BX0FHR1JFU1NJVkUgaXMgYXZhaWxhYmxlLCB3aGVuIExpbnV4 IGtlcm5lbCBjYWxsIGZ1bmN0aW9uCj4+IF9fcm1xdWV1ZSB0cnkgdG8gZ2V0IHBhZ2VzIGZyb20g TUlHUkFURV9NT1ZBQkxFIGFuZCBjb25kaXRpb25zIGFsbG93LAo+PiBNSUdSQVRFX0NNQSB3aWxs IGJlIGFsbG9jYXRlZCBhcyBNSUdSQVRFX01PVkFCTEUgZmlyc3QuICBJZiBNSUdSQVRFX0NNQQo+ PiBkb2Vzbid0IGhhdmUgZW5vdWdoIHBhZ2VzIGZvciBhbGxvY2F0aW9uLCBnbyBiYWNrIHRvIGFs bG9jYXRlIG1lbW9yeSBmcm9tCj4+IE1JR1JBVEVfTU9WQUJMRS4KPj4gVGhlbiB0aGUgbWVtb3J5 IG9mIE1JR1JBVEVfTU9WQUJMRSBjYW4gYmUga2VwdCBmb3IgTUlHUkFURV9VTk1PVkFCTEUgYW5k Cj4+IE1JR1JBVEVfUkVDTEFJTUFCTEUgd2hpY2ggZG9lc24ndCBoYXZlIGZhbGxiYWNrIE1JR1JB VEVfQ01BLgo+Pgo+Cj4gSXQncyBnb29kIHRvIHNlZSBhbm90aGVyIHByb3Bvc2FsIHRvIGZpeCBD TUEgdXRpbGl6YXRpb24uCgpUaGFua3MgTGF1cmEuCgpEbyB5b3UgaGF2ZQo+IGFueSBkYXRhIGFi b3V0IHRoZSBzdWNjZXNzIHJhdGUgb2YgQ01BIGNvbnRpZ3VvdXMgYWxsb2NhdGlvbiBhZnRlcgo+ IHRoaXMgcGF0Y2ggc2VyaWVzPyAgIEkgcGxheWVkIGFyb3VuZCB3aXRoIGEgc2ltaWxhciBhcHBy b2FjaCBvZiB1c2luZwo+IENNQSBmb3IgTUlHUkFURV9NT1ZBQkxFIGFsbG9jYXRpb25zIGFuZCBm b3VuZCB0aGF0IGFsdGhvdWdoIHV0aWxpemF0aW9uCj4gZGlkIGluY3JlYXNlLCBjb250aWd1b3Vz IGFsbG9jYXRpb25zIGZhaWxlZCBhdCBhIGhpZ2hlciByYXRlIGFuZCB3ZXJlCj4gbXVjaCBzbG93 ZXIuIEkgc2VlIHdoYXQgdGhpcyBzZXJpZXMgaXMgdHJ5aW5nIHRvIGRvIHdpdGggYXZvaWRpbmcK PiBhbGxvY2F0aW9uIGZyb20gQ01BIHBhZ2VzIHdoZW4gYSBjb250aWd1b3VzIGFsbG9jYXRpb24g aXMgcHJvZ3Jlc3MuCj4gTXkgY29uY2VybiBpcyB0aGF0IHRoZXJlIHdvdWxkIHN0aWxsIGJlIHBy b2JsZW1zIHdpdGggY29udGlndW91cwo+IGFsbG9jYXRpb24gYWZ0ZXIgYWxsIHRoZSBNSUdSQVRF X01PVkFCTEUgZmFsbGJhY2sgaGFzIGhhcHBlbmVkLgoKSSBkaWQgc29tZSB0ZXN0IHdpdGggdGhl IGNtYV9hbGxvY19jb3VudGVyIGFuZCBjbWEtYWdncmVzc2l2ZS1zaHJpbmsgaW4gCmEgYW5kcm9p ZCBib2FyZCB0aGF0IGhhcyAxZyBtZW1vcnkuICBSdW4gc29tZSBhcHBzIHRvIG1ha2UgZnJlZSBD TUEgCmNsb3NlIHRvIHRoZSB2YWx1ZSBvZiBjbWFfYWdncmVzc2l2ZV9mcmVlX21pbig1MDAgcGFn ZXMpLiAgQSBkcml2ZXIgCkJlZ2luIHRvIHJlcXVlc3QgQ01BIG1vcmUgdGhhbiAxMCB0aW1lcy4g RWFjaCB0aW1lLCBpdCB3aWxsIHJlcXVlc3QgbW9yZSAKdGhhbiAzMDAwIHBhZ2VzLgoKSSBkb24n dCBoYXZlIGVzdGFibGlzaGVkIG51bWJlciBmb3IgdGhhdCBiZWNhdXNlIGl0IGlzIHJlYWxseSBo YXJkIHRvIApnZXQgYSBmYWlsLiAgSSB0aGluayB0aGUgc3VjY2VzcyByYXRlIGlzIG92ZXIgOTUl IGF0IGxlYXN0LgoKQW5kIEkgdGhpbmsgbWF5YmUgdGhlIGlzb2xhdGUgZmFpbCBoYXMgcmVsYXRp b24gd2l0aCBwYWdlIGFsbG9jIGFuZCBmcmVlIApjb2RlLiAgTWF5YmUgbGV0IHpvbmUtPmxvY2sg cHJvdGVjdCBtb3JlIGNvZGUgY2FuIGhhbmRsZSB0aGlzIGlzc3VlLgoKVGhhbmtzLApIdWkKCj4K PiBUaGFua3MsCj4gTGF1cmEKPgo= -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by kanga.kvack.org (Postfix) with ESMTP id 5E8DF6B0069 for ; Fri, 17 Oct 2014 05:28:54 -0400 (EDT) Received: by mail-pd0-f179.google.com with SMTP id r10so490658pdi.10 for ; Fri, 17 Oct 2014 02:28:54 -0700 (PDT) Received: from manager.mioffice.cn ([42.62.48.242]) by mx.google.com with ESMTP id te6si580252pbc.227.2014.10.17.02.28.49 for ; Fri, 17 Oct 2014 02:28:53 -0700 (PDT) From: Hui Zhu Subject: [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma Date: Fri, 17 Oct 2014 17:28:04 +0800 Message-ID: <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> In-Reply-To: <1471435.6q4YYkTopF@vostro.rjw.lan> References: <1471435.6q4YYkTopF@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Update this patch according to the comments from Rafael. Function shrink_all_memory_for_cma try to free `nr_to_reclaim' of memory. CMA aggressive shrink function will call this functon to free `nr_to_reclaim' of memory. Signed-off-by: Hui Zhu --- mm/vmscan.c | 58 +++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..658dc8d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,6 +3404,28 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE +static unsigned long __shrink_all_memory(struct scan_control *sc) +{ + struct reclaim_state reclaim_state; + struct zonelist *zonelist = node_zonelist(numa_node_id(), sc->gfp_mask); + struct task_struct *p = current; + unsigned long nr_reclaimed; + + p->flags |= PF_MEMALLOC; + lockdep_set_current_reclaim_state(sc->gfp_mask); + reclaim_state.reclaimed_slab = 0; + p->reclaim_state = &reclaim_state; + + nr_reclaimed = do_try_to_free_pages(zonelist, sc); + + p->reclaim_state = NULL; + lockdep_clear_current_reclaim_state(); + p->flags &= ~PF_MEMALLOC; + + return nr_reclaimed; +} + #ifdef CONFIG_HIBERNATION /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of @@ -3415,7 +3437,6 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) */ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) { - struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, .gfp_mask = GFP_HIGHUSER_MOVABLE, @@ -3425,24 +3446,31 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) .may_swap = 1, .hibernation_mode = 1, }; - struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); - struct task_struct *p = current; - unsigned long nr_reclaimed; - - p->flags |= PF_MEMALLOC; - lockdep_set_current_reclaim_state(sc.gfp_mask); - reclaim_state.reclaimed_slab = 0; - p->reclaim_state = &reclaim_state; - nr_reclaimed = do_try_to_free_pages(zonelist, &sc); + return __shrink_all_memory(&sc); +} +#endif /* CONFIG_HIBERNATION */ - p->reclaim_state = NULL; - lockdep_clear_current_reclaim_state(); - p->flags &= ~PF_MEMALLOC; +#ifdef CONFIG_CMA_AGGRESSIVE +/* + * Try to free `nr_to_reclaim' of memory, system-wide, for CMA aggressive + * shrink function. + */ +void shrink_all_memory_for_cma(unsigned long nr_to_reclaim) +{ + struct scan_control sc = { + .nr_to_reclaim = nr_to_reclaim, + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM, + .priority = DEF_PRIORITY, + .may_writepage = !laptop_mode, + .may_unmap = 1, + .may_swap = 1, + }; - return nr_reclaimed; + __shrink_all_memory(&sc); } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_CMA_AGGRESSIVE */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by kanga.kvack.org (Postfix) with ESMTP id A69016B006C for ; Fri, 17 Oct 2014 05:30:33 -0400 (EDT) Received: by mail-pd0-f180.google.com with SMTP id fp1so474743pdb.25 for ; Fri, 17 Oct 2014 02:30:33 -0700 (PDT) Received: from manager.mioffice.cn ([42.62.48.242]) by mx.google.com with ESMTP id ra2si599374pbb.207.2014.10.17.02.30.16 for ; Fri, 17 Oct 2014 02:30:32 -0700 (PDT) From: Hui Zhu Subject: [PATCH v2 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Date: Fri, 17 Oct 2014 17:30:05 +0800 Message-ID: <1413538205-15915-1-git-send-email-zhuhui@xiaomi.com> In-Reply-To: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Update this patch according to the comments from Rafael. Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and cma_aggressive_shrink_switch. cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be controlled by sysctl vm.cma-aggressive-switch. cma_aggressive_free_min can be controlled by sysctl "vm.cma-aggressive-free-min". If the number of CMA free pages is small than this sysctl value, CMA_AGGRESSIVE will not work in page alloc code. cma_aggressive_shrink_switch can be controlled by sysctl "vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal memory's size is smaller than the size that it want to allocate, do memory shrink with function git commit -a --amend before driver allocate pages from CMA. When Linux kernel try to reserve custom contiguous area, increase the value of cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code. After reserve custom contiguous area function return, decreases the value of cma_alloc_counter. Signed-off-by: Hui Zhu --- include/linux/cma.h | 7 +++++++ kernel/sysctl.c | 27 +++++++++++++++++++++++++++ mm/cma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) diff --git a/include/linux/cma.h b/include/linux/cma.h index 0430ed0..df96abf 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -15,6 +15,13 @@ struct cma; +#ifdef CONFIG_CMA_AGGRESSIVE +extern atomic_t cma_alloc_counter; +extern int cma_aggressive_switch; +extern unsigned long cma_aggressive_free_min; +extern int cma_aggressive_shrink_switch; +#endif + extern phys_addr_t cma_get_base(struct cma *cma); extern unsigned long cma_get_size(struct cma *cma); diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 4aada6d..646929e2 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -92,6 +92,10 @@ #include #endif +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + #if defined(CONFIG_SYSCTL) @@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_CMA_AGGRESSIVE + { + .procname = "cma-aggressive-switch", + .data = &cma_aggressive_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, + { + .procname = "cma-aggressive-free-min", + .data = &cma_aggressive_free_min, + .maxlen = sizeof(unsigned long), + .mode = 0600, + .proc_handler = proc_doulongvec_minmax, + }, + { + .procname = "cma-aggressive-shrink-switch", + .data = &cma_aggressive_shrink_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, +#endif { } }; diff --git a/mm/cma.c b/mm/cma.c index 963bc4a..1cf341c 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -33,6 +33,7 @@ #include #include #include +#include struct cma { unsigned long base_pfn; @@ -127,6 +128,27 @@ err: return -EINVAL; } +#ifdef CONFIG_CMA_AGGRESSIVE +/* The counter for the dma_alloc_from_contiguous and + dma_release_from_contiguous. */ +atomic_t cma_alloc_counter = ATOMIC_INIT(0); + +/* Swich of CMA_AGGRESSIVE. */ +int cma_aggressive_switch __read_mostly; + +/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE will + not work. */ +#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN +unsigned long cma_aggressive_free_min __read_mostly = + CONFIG_CMA_AGGRESSIVE_FREE_MIN; +#else +unsigned long cma_aggressive_free_min __read_mostly = 500; +#endif + +/* Swich of CMA_AGGRESSIVE shink. */ +int cma_aggressive_shrink_switch __read_mostly; +#endif + static int __init cma_init_reserved_areas(void) { int i; @@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void) return ret; } +#ifdef CONFIG_CMA_AGGRESSIVE + cma_aggressive_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX + if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX) +#else + if (memblock_phys_mem_size() <= 0x40000000) +#endif + cma_aggressive_switch = 1; + + cma_aggressive_shrink_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK + if (cma_aggressive_switch) + cma_aggressive_shrink_switch = 1; +#endif +#endif + return 0; } core_initcall(cma_init_reserved_areas); @@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) unsigned long bitmap_maxno, bitmap_no, bitmap_count; struct page *page = NULL; int ret; +#ifdef CONFIG_CMA_AGGRESSIVE + int free = global_page_state(NR_FREE_PAGES) + - global_page_state(NR_FREE_CMA_PAGES) + - totalreserve_pages; +#endif if (!cma || !cma->count) return NULL; @@ -326,6 +369,13 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) bitmap_maxno = cma_bitmap_maxno(cma); bitmap_count = cma_bitmap_pages_to_bits(cma, count); +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_inc(&cma_alloc_counter); + if (cma_aggressive_switch && cma_aggressive_shrink_switch + && free < count) + shrink_all_memory_for_cma(count - free); +#endif + for (;;) { mutex_lock(&cma->lock); bitmap_no = bitmap_find_next_zero_area(cma->bitmap, @@ -361,6 +411,10 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) start = bitmap_no + mask + 1; } +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_dec(&cma_alloc_counter); +#endif + pr_debug("%s(): returned %p\n", __func__, page); return page; } -- 1.9.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by kanga.kvack.org (Postfix) with ESMTP id 729696B0069 for ; Sat, 18 Oct 2014 00:50:11 -0400 (EDT) Received: by mail-qc0-f170.google.com with SMTP id m20so1599410qcx.15 for ; Fri, 17 Oct 2014 21:50:11 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com. [98.139.212.175]) by mx.google.com with ESMTPS id u8si5564252qcj.26.2014.10.17.21.50.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 21:50:09 -0700 (PDT) References: <1471435.6q4YYkTopF@vostro.rjw.lan> <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> Message-ID: <1413607808.82877.YahooMailNeo@web160105.mail.bf1.yahoo.com> Date: Fri, 17 Oct 2014 21:50:08 -0700 From: PINTU KUMAR Reply-To: PINTU KUMAR Subject: Re: [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma In-Reply-To: <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Hui Zhu , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "akinobu.mita@gmail.com" , "lauraa@codeaurora.org" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" Cc: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "pintu_agarwal@yahoo.com" , "pintu.k@samsung.com" Hi,=0A=0A=0A=0A----- Original Message -----=0A> From: Hui Zhu =0A> To: rjw@rjwysocki.net; len.brown@intel.com; pavel@ucw.cz; m.szyp= rowski@samsung.com; akpm@linux-foundation.org; mina86@mina86.com; aneesh.ku= mar@linux.vnet.ibm.com; iamjoonsoo.kim@lge.com; hannes@cmpxchg.org; riel@re= dhat.com; mgorman@suse.de; minchan@kernel.org; nasa4836@gmail.com; ddstreet= @ieee.org; hughd@google.com; mingo@kernel.org; rientjes@google.com; peterz@= infradead.org; keescook@chromium.org; atomlin@redhat.com; raistlin@linux.it= ; axboe@fb.com; paulmck@linux.vnet.ibm.com; kirill.shutemov@linux.intel.com= ; n-horiguchi@ah.jp.nec.com; k.khlebnikov@samsung.com; msalter@redhat.com; = deller@gmx.de; tangchen@cn.fujitsu.com; ben@decadent.org.uk; akinobu.mita@g= mail.com; lauraa@codeaurora.org; vbabka@suse.cz; sasha.levin@oracle.com; vd= avydov@parallels.com; suleiman@google.com=0A> Cc: linux-kernel@vger.kernel.= org; linux-pm@vger.kernel.org; linux-mm@kvack.org; Hui Zhu =0A> Sent: Friday, 17 October 2014 2:58 PM=0A> Subject: [PATCH v2 2/4] (= CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma=0A> =0A> Update = this patch according to the comments from Rafael.=0A> =0A> Function shrink_= all_memory_for_cma try to free `nr_to_reclaim' of memory.=0A> CMA aggressiv= e shrink function will call this functon to free =0A> `nr_to_reclaim' of=0A= > memory.=0A=0AInstead, we can have in short shrink_cma_memory(nr_to_reclai= m).=0ASometime back I already proposed to have shrink_memory for CMA here:= =0Ahttp://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/14310= 3.html=0A=0ANow, I am working on another solution that uses shrink_all_memo= ry().=0AThis can be helpful even for non CMA cases as well to bring back th= e higher-order pages quickly.=0AWill post the patches until next week.=0A= =0A=0A> =0A> Signed-off-by: Hui Zhu =0A> ---=0A> mm/vmsc= an.c | 58 +++++++++++++++++++++++++++++++++++++++++++---------------=0A> 1 = file changed, 43 insertions(+), 15 deletions(-)=0A> =0A> diff --git a/mm/vm= scan.c b/mm/vmscan.c=0A> index dcb4707..658dc8d 100644=0A> --- a/mm/vmscan.= c=0A> +++ b/mm/vmscan.c=0A> @@ -3404,6 +3404,28 @@ void wakeup_kswapd(struc= t zone *zone, int order, enum =0A> zone_type classzone_idx)=0A> wake_up= _interruptible(&pgdat->kswapd_wait);=0A> }=0A> =0A> +#if defined CONFIG_HIB= ERNATION || defined CONFIG_CMA_AGGRESSIVE=0A> +static unsigned long __shrin= k_all_memory(struct scan_control *sc)=0A> +{=0A> + struct reclaim_state = reclaim_state;=0A> + struct zonelist *zonelist =3D node_zonelist(numa_no= de_id(), sc->gfp_mask);=0A> + struct task_struct *p =3D current;=0A> + = unsigned long nr_reclaimed;=0A> +=0A> + p->flags |=3D PF_MEMALLOC;=0A>= + lockdep_set_current_reclaim_state(sc->gfp_mask);=0A> + reclaim_sta= te.reclaimed_slab =3D 0;=0A> + p->reclaim_state =3D &reclaim_state;=0A> = +=0A> + nr_reclaimed =3D do_try_to_free_pages(zonelist, sc);=0A> +=0A> += p->reclaim_state =3D NULL;=0A> + lockdep_clear_current_reclaim_state= ();=0A> + p->flags &=3D ~PF_MEMALLOC;=0A> +=0A> + return nr_reclaimed= ;=0A> +}=0A> +=0A> #ifdef CONFIG_HIBERNATION=0A> /*=0A> * Try to free `nr= _to_reclaim' of memory, system-wide, and return the =0A> number of=0A> @@ -= 3415,7 +3437,6 @@ void wakeup_kswapd(struct zone *zone, int order, enum =0A= > zone_type classzone_idx)=0A> */=0A> unsigned long shrink_all_memory(uns= igned long nr_to_reclaim)=0A> {=0A> - struct reclaim_state reclaim_state= ;=0A> struct scan_control sc =3D {=0A> .nr_to_reclaim =3D nr_to= _reclaim,=0A> .gfp_mask =3D GFP_HIGHUSER_MOVABLE,=0A> @@ -3425,24 += 3446,31 @@ unsigned long shrink_all_memory(unsigned long =0A> nr_to_reclaim= )=0A> .may_swap =3D 1,=0A> .hibernation_mode =3D 1,=0A> = };=0A> - struct zonelist *zonelist =3D node_zonelist(numa_node_id(), sc= .gfp_mask);=0A> - struct task_struct *p =3D current;=0A> - unsigned l= ong nr_reclaimed;=0A> -=0A> - p->flags |=3D PF_MEMALLOC;=0A> - lockde= p_set_current_reclaim_state(sc.gfp_mask);=0A> - reclaim_state.reclaimed_= slab =3D 0;=0A> - p->reclaim_state =3D &reclaim_state;=0A> =0A> - nr_= reclaimed =3D do_try_to_free_pages(zonelist, &sc);=0A> + return __shrink= _all_memory(&sc);=0A> +}=0A> +#endif /* CONFIG_HIBERNATION */=0A> =0A> - = p->reclaim_state =3D NULL;=0A> - lockdep_clear_current_reclaim_state();= =0A> - p->flags &=3D ~PF_MEMALLOC;=0A> +#ifdef CONFIG_CMA_AGGRESSIVE=0A>= +/*=0A> + * Try to free `nr_to_reclaim' of memory, system-wide, for CMA ag= gressive=0A> + * shrink function.=0A> + */=0A> +void shrink_all_memory_for_= cma(unsigned long nr_to_reclaim)=0A> +{=0A> + struct scan_control sc =3D= {=0A> + .nr_to_reclaim =3D nr_to_reclaim,=0A> + .gfp_mask = =3D GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM,=0A> + .priority =3D DE= F_PRIORITY,=0A> + .may_writepage =3D !laptop_mode,=0A> + .may= _unmap =3D 1,=0A> + .may_swap =3D 1,=0A> + };=0A> =0A> - retur= n nr_reclaimed;=0A> + __shrink_all_memory(&sc);=0A> }=0A> -#endif /* CON= FIG_HIBERNATION */=0A> +#endif /* CONFIG_CMA_AGGRESSIVE */=0A> +#endif /* C= ONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */=0A> =0A> /* It's optimal to k= eep kswapds on the same CPUs as their memory, but=0A> not required for = correctness. So if the last cpu in a node goes=0A> -- =0A> 1.9.1=0A> =0A> = =0A> --=0A> To unsubscribe, send a message with 'unsubscribe linux-mm' in= =0A> the body to majordomo@kvack.org. For more info on Linux MM,=0A> see: = http://www.linux-mm.org/ .=0A> Don't email: =0A> email@kvack.org =0A> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by kanga.kvack.org (Postfix) with ESMTP id DADA86B0069 for ; Sat, 18 Oct 2014 18:15:27 -0400 (EDT) Received: by mail-wg0-f51.google.com with SMTP id b13so3048809wgh.10 for ; Sat, 18 Oct 2014 15:15:27 -0700 (PDT) Received: from atrey.karlin.mff.cuni.cz (atrey.karlin.mff.cuni.cz. [195.113.26.193]) by mx.google.com with ESMTP id x5si5572646wjy.76.2014.10.18.15.15.25 for ; Sat, 18 Oct 2014 15:15:26 -0700 (PDT) Date: Sun, 19 Oct 2014 00:15:25 +0200 From: Pavel Machek Subject: Re: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Message-ID: <20141018221525.GB10843@amd> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org List-ID: To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Hi! > Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. > Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK > that depend on CMA_AGGRESSIVE. > > If physical memory size (not include CMA memory) in byte less than or equal to > CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) > will be opened. Ok... Do I understand it correctly that there is some problem with hibernation not working on machines not working on machines with big CMA areas...? But adding 4 config options end-user has no chance to set right can not be the best solution, can it? > +config CMA_AGGRESSIVE_PHY_MAX > + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" > + depends on CMA_AGGRESSIVE > + default 0x40000000 > + help > + If physical memory size (not include CMA memory) in byte less than or > + equal to this value, CMA aggressive switch will be opened. > + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control > + the CMA AGGRESSIVE switch. For example... how am I expected to figure right value to place here? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id 9115B6B006E for ; Wed, 22 Oct 2014 01:44:30 -0400 (EDT) Received: by mail-pd0-f181.google.com with SMTP id w10so2788769pde.26 for ; Tue, 21 Oct 2014 22:44:30 -0700 (PDT) Received: from manager.mioffice.cn ([42.62.48.242]) by mx.google.com with ESMTP id p1si13236941pdp.169.2014.10.21.22.44.27 for ; Tue, 21 Oct 2014 22:44:29 -0700 (PDT) From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Date: Wed, 22 Oct 2014 05:44:24 +0000 Message-ID: <2c27ad87839b42ca85c03c9541550d30@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> <201410220126.s9M1Qita026502@spam.xiaomi.com> Content-Language: zh-CN Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Pavel Machek Cc: "rjw@rjwysocki.net" , "len.brown@intel.com" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "akinobu.mita@gmail.com" , "lauraa@codeaurora.org" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" CgpPbiAxMC8yMi8xNCAwOToyNywgUGF2ZWwgTWFjaGVrIHdyb3RlOgo+IEhpIQo+Cj4+IEFkZCBD TUFfQUdHUkVTU0lWRSBjb25maWcgdGhhdCBkZXBlbmQgb24gQ01BIHRvIExpbnV4IGtlcm5lbCBj b25maWcuCj4+IEFkZCBDTUFfQUdHUkVTU0lWRV9QSFlfTUFYLCBDTUFfQUdHUkVTU0lWRV9GUkVF X01JTiBhbmQgQ01BX0FHR1JFU1NJVkVfU0hSSU5LCj4+IHRoYXQgZGVwZW5kIG9uIENNQV9BR0dS RVNTSVZFLgo+Pgo+PiBJZiBwaHlzaWNhbCBtZW1vcnkgc2l6ZSAobm90IGluY2x1ZGUgQ01BIG1l bW9yeSkgaW4gYnl0ZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG8KPj4gQ01BX0FHR1JFU1NJVkVfUEhZ X01BWCwgQ01BIGFnZ3Jlc3NpdmUgc3dpdGNoIChzeXNjdGwgdm0uY21hLWFnZ3Jlc3NpdmUtc3dp dGNoKQo+PiB3aWxsIGJlIG9wZW5lZC4KPgo+IE9rLi4uCj4KPiBEbyBJIHVuZGVyc3RhbmQgaXQg Y29ycmVjdGx5IHRoYXQgdGhlcmUgaXMgc29tZSBwcm9ibGVtIHdpdGgKPiBoaWJlcm5hdGlvbiBu b3Qgd29ya2luZyBvbiBtYWNoaW5lcyBub3Qgd29ya2luZyBvbiBtYWNoaW5lcyB3aXRoIGJpZwo+ IENNQSBhcmVhcy4uLj8KCk5vLCB0aGVzZSBwYXRjaGVzIHdhbnQgdG8gaGFuZGxlIHRoaXMgaXNz dWUgdGhhdCBtb3N0IG9mIENNQSBtZW1vcnkgaXMgCm5vdCBhbGxvY2F0ZWQgYmVmb3JlIGxvd21l bW9yeWtpbGxlciBvciBvb21fa2lsbGVyIGJlZ2luIHRvIGtpbGwgdGFza3MuCgo+Cj4gQnV0IGFk ZGluZyA0IGNvbmZpZyBvcHRpb25zIGVuZC11c2VyIGhhcyBubyBjaGFuY2UgdG8gc2V0IHJpZ2h0 IGNhbgo+IG5vdCBiZSB0aGUgYmVzdCBzb2x1dGlvbiwgY2FuIGl0Pwo+Cj4+ICtjb25maWcgQ01B X0FHR1JFU1NJVkVfUEhZX01BWAo+PiArCWhleCAiUGh5c2ljYWwgbWVtb3J5IHNpemUgaW4gQnl0 ZXMgdGhhdCBhdXRvIHR1cm4gb24gdGhlIENNQSBhZ2dyZXNzaXZlIHN3aXRjaCIKPj4gKwlkZXBl bmRzIG9uIENNQV9BR0dSRVNTSVZFCj4+ICsJZGVmYXVsdCAweDQwMDAwMDAwCj4+ICsJaGVscAo+ PiArCSAgSWYgcGh5c2ljYWwgbWVtb3J5IHNpemUgKG5vdCBpbmNsdWRlIENNQSBtZW1vcnkpIGlu IGJ5dGUgbGVzcyB0aGFuIG9yCj4+ICsJICBlcXVhbCB0byB0aGlzIHZhbHVlLCBDTUEgYWdncmVz c2l2ZSBzd2l0Y2ggd2lsbCBiZSBvcGVuZWQuCj4+ICsJICBBZnRlciB0aGUgTGludXggYm9vdCwg c3lzY3RsICJ2bS5jbWEtYWdncmVzc2l2ZS1zd2l0Y2giIGNhbiBjb250cm9sCj4+ICsJICB0aGUg Q01BIEFHR1JFU1NJVkUgc3dpdGNoLgo+Cj4gRm9yIGV4YW1wbGUuLi4gaG93IGFtIEkgZXhwZWN0 ZWQgdG8gZmlndXJlIHJpZ2h0IHZhbHVlIHRvIHBsYWNlIGhlcmU/CgpJIGFncmVlIHdpdGggdGhh dC4gIEkgd2lsbCB1cGRhdGUgdGhpcyBjb25maWcgdG8gYXV0byBzZXQgaW4gbmV4dCB2ZXJzaW9u LgoKVGhhbmtzLApIdWkKCj4KPiAJCQkJCQkJCQlQYXZlbAo+Cg== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by kanga.kvack.org (Postfix) with ESMTP id BB68E6B0069 for ; Wed, 22 Oct 2014 20:41:15 -0400 (EDT) Received: by mail-pa0-f51.google.com with SMTP id lj1so4714350pab.24 for ; Wed, 22 Oct 2014 17:41:15 -0700 (PDT) Received: from outbound.mxmail.xiaomi.com ([42.62.48.242]) by mx.google.com with ESMTP id hk4si145904pbc.190.2014.10.22.17.41.13 for ; Wed, 22 Oct 2014 17:41:14 -0700 (PDT) From: =?gb2312?B?1uy71A==?= Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 23 Oct 2014 00:40:57 +0000 Message-ID: <04a07ed889c840f1919e220f906af3af@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <54479CB2.5040408@hurleysoftware.com> Content-Language: zh-CN Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Peter Hurley , Laura Abbott , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "riel@redhat.com" , "mgorman@suse.de" , "hughd@google.com" , "akinobu.mita@gmail.com" Cc: "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" CgpPbiAxMC8yMi8xNCAyMDowMiwgUGV0ZXIgSHVybGV5IHdyb3RlOgo+IE9uIDEwLzE2LzIwMTQg MDQ6NTUgQU0sIExhdXJhIEFiYm90dCB3cm90ZToKPj4gT24gMTAvMTUvMjAxNCA4OjM1IFBNLCBI dWkgWmh1IHdyb3RlOgo+Pj4gSW4gZmFsbGJhY2tzIG9mIHBhZ2VfYWxsb2MuYywgTUlHUkFURV9D TUEgaXMgdGhlIGZhbGxiYWNrIG9mCj4+PiBNSUdSQVRFX01PVkFCTEUuCj4+PiBNSUdSQVRFX01P VkFCTEUgd2lsbCB1c2UgTUlHUkFURV9DTUEgd2hlbiBpdCBkb2Vzbid0IGhhdmUgYSBwYWdlIGlu Cj4+PiBvcmRlciB0aGF0IExpbnV4IGtlcm5lbCB3YW50Lgo+Pj4KPj4+IElmIGEgc3lzdGVtIHRo YXQgaGFzIGEgbG90IG9mIHVzZXIgc3BhY2UgcHJvZ3JhbSBpcyBydW5uaW5nLCBmb3IKPj4+IGlu c3RhbmNlLCBhbiBBbmRyb2lkIGJvYXJkLCBtb3N0IG9mIG1lbW9yeSBpcyBpbiBNSUdSQVRFX01P VkFCTEUgYW5kCj4+PiBhbGxvY2F0ZWQuICBCZWZvcmUgZnVuY3Rpb24gX19ybXF1ZXVlX2ZhbGxi YWNrIGdldCBtZW1vcnkgZnJvbQo+Pj4gTUlHUkFURV9DTUEsIHRoZSBvb21fa2lsbGVyIHdpbGwg a2lsbCBhIHRhc2sgdG8gcmVsZWFzZSBtZW1vcnkgd2hlbgo+Pj4ga2VybmVsIHdhbnQgZ2V0IE1J R1JBVEVfVU5NT1ZBQkxFIG1lbW9yeSBiZWNhdXNlIGZhbGxiYWNrcyBvZgo+Pj4gTUlHUkFURV9V Tk1PVkFCTEUgYXJlIE1JR1JBVEVfUkVDTEFJTUFCTEUgYW5kIE1JR1JBVEVfTU9WQUJMRS4KPj4+ IFRoaXMgc3RhdHVzIGlzIG9kZC4gIFRoZSBNSUdSQVRFX0NNQSBoYXMgYSBsb3QgZnJlZSBtZW1v cnkgYnV0IExpbnV4Cj4+PiBrZXJuZWwga2lsbCBzb21lIHRhc2tzIHRvIHJlbGVhc2UgbWVtb3J5 Lgo+Pj4KPj4+IFRoaXMgcGF0Y2ggc2VyaWVzIGFkZHMgYSBuZXcgZnVuY3Rpb24gQ01BX0FHR1JF U1NJVkUgdG8gbWFrZSBDTUEgbWVtb3J5Cj4+PiBiZSBtb3JlIGFnZ3Jlc3NpdmUgYWJvdXQgYWxs b2NhdGlvbi4KPj4+IElmIGZ1bmN0aW9uIENNQV9BR0dSRVNTSVZFIGlzIGF2YWlsYWJsZSwgd2hl biBMaW51eCBrZXJuZWwgY2FsbCBmdW5jdGlvbgo+Pj4gX19ybXF1ZXVlIHRyeSB0byBnZXQgcGFn ZXMgZnJvbSBNSUdSQVRFX01PVkFCTEUgYW5kIGNvbmRpdGlvbnMgYWxsb3csCj4+PiBNSUdSQVRF X0NNQSB3aWxsIGJlIGFsbG9jYXRlZCBhcyBNSUdSQVRFX01PVkFCTEUgZmlyc3QuICBJZiBNSUdS QVRFX0NNQQo+Pj4gZG9lc24ndCBoYXZlIGVub3VnaCBwYWdlcyBmb3IgYWxsb2NhdGlvbiwgZ28g YmFjayB0byBhbGxvY2F0ZSBtZW1vcnkgZnJvbQo+Pj4gTUlHUkFURV9NT1ZBQkxFLgo+Pj4gVGhl biB0aGUgbWVtb3J5IG9mIE1JR1JBVEVfTU9WQUJMRSBjYW4gYmUga2VwdCBmb3IgTUlHUkFURV9V Tk1PVkFCTEUgYW5kCj4+PiBNSUdSQVRFX1JFQ0xBSU1BQkxFIHdoaWNoIGRvZXNuJ3QgaGF2ZSBm YWxsYmFjayBNSUdSQVRFX0NNQS4KPj4+Cj4+Cj4+IEl0J3MgZ29vZCB0byBzZWUgYW5vdGhlciBw cm9wb3NhbCB0byBmaXggQ01BIHV0aWxpemF0aW9uLiBEbyB5b3UgaGF2ZQo+PiBhbnkgZGF0YSBh Ym91dCB0aGUgc3VjY2VzcyByYXRlIG9mIENNQSBjb250aWd1b3VzIGFsbG9jYXRpb24gYWZ0ZXIK Pj4gdGhpcyBwYXRjaCBzZXJpZXM/IEkgcGxheWVkIGFyb3VuZCB3aXRoIGEgc2ltaWxhciBhcHBy b2FjaCBvZiB1c2luZwo+PiBDTUEgZm9yIE1JR1JBVEVfTU9WQUJMRSBhbGxvY2F0aW9ucyBhbmQg Zm91bmQgdGhhdCBhbHRob3VnaCB1dGlsaXphdGlvbgo+PiBkaWQgaW5jcmVhc2UsIGNvbnRpZ3Vv dXMgYWxsb2NhdGlvbnMgZmFpbGVkIGF0IGEgaGlnaGVyIHJhdGUgYW5kIHdlcmUKPj4gbXVjaCBz bG93ZXIuIEkgc2VlIHdoYXQgdGhpcyBzZXJpZXMgaXMgdHJ5aW5nIHRvIGRvIHdpdGggYXZvaWRp bmcKPj4gYWxsb2NhdGlvbiBmcm9tIENNQSBwYWdlcyB3aGVuIGEgY29udGlndW91cyBhbGxvY2F0 aW9uIGlzIHByb2dyZXNzLgo+PiBNeSBjb25jZXJuIGlzIHRoYXQgdGhlcmUgd291bGQgc3RpbGwg YmUgcHJvYmxlbXMgd2l0aCBjb250aWd1b3VzCj4+IGFsbG9jYXRpb24gYWZ0ZXIgYWxsIHRoZSBN SUdSQVRFX01PVkFCTEUgZmFsbGJhY2sgaGFzIGhhcHBlbmVkLgo+Cj4gV2hhdCBpbXBhY3QgZG9l cyB0aGlzIHNlcmllcyBoYXZlIG9uIHg4NiBwbGF0Zm9ybXMgbm93IHRoYXQgQ01BIGlzIHRoZQo+ IGJhY2t1cCBhbGxvY2F0b3IgZm9yIGFsbCBpb21tdSBkbWEgYWxsb2NhdGlvbnM/CgpUaGV5IHdp bGwgbm90IGFmZmVjdCBkcml2ZXIgQ01BIG1lbW9yeSBhbGxvY2F0aW9uLgoKVGhhbmtzLApIdWkK Cj4KPiBSZWdhcmRzLAo+IFBldGVyIEh1cmxleQo+Cg== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id 7CCCC82BDA for ; Fri, 24 Oct 2014 01:24:51 -0400 (EDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so489099pad.7 for ; Thu, 23 Oct 2014 22:24:51 -0700 (PDT) Received: from lgemrelse7q.lge.com (LGEMRELSE7Q.lge.com. [156.147.1.151]) by mx.google.com with ESMTP id bb10si3295335pbd.144.2014.10.23.22.24.49 for ; Thu, 23 Oct 2014 22:24:50 -0700 (PDT) Date: Fri, 24 Oct 2014 14:25:53 +0900 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141024052553.GE15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Sender: owner-linux-mm@kvack.org List-ID: To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. > > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. Hello, I did some work similar to this. Please reference following links. https://lkml.org/lkml/2014/5/28/64 https://lkml.org/lkml/2014/5/28/57 And, aggressive allocation should be postponed until freepage counting bug is fixed, because aggressive allocation enlarge the possiblity of problem occurence. I tried to fix that bug, too. See following link. https://lkml.org/lkml/2014/10/23/90 Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by kanga.kvack.org (Postfix) with ESMTP id 74E95900021 for ; Wed, 29 Oct 2014 10:43:44 -0400 (EDT) Received: by mail-lb0-f172.google.com with SMTP id n15so2587809lbi.31 for ; Wed, 29 Oct 2014 07:43:43 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id g7si7513868lab.66.2014.10.29.07.43.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 07:43:41 -0700 (PDT) Message-ID: <5450FD15.4000708@suse.cz> Date: Wed, 29 Oct 2014 15:43:33 +0100 From: Vlastimil Babka MIME-Version: 1.0 Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> In-Reply-To: <543F8812.2020002@codeaurora.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org 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 - it's more complex, but I guess we have most of the necessary infrastructure in compaction already :) Thoughts? Vlastimil > Thanks, > Laura > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by kanga.kvack.org (Postfix) with ESMTP id C067A6B00BC for ; Mon, 3 Nov 2014 02:29:20 -0500 (EST) Received: by mail-oi0-f54.google.com with SMTP id a141so6564337oig.41 for ; Sun, 02 Nov 2014 23:29:20 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com. [2607:f8b0:4003:c06::235]) by mx.google.com with ESMTPS id o81si17754898oib.83.2014.11.02.23.29.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 23:29:19 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id a141so6681719oig.12 for ; Sun, 02 Nov 2014 23:29:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20141024052553.GE15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> From: Hui Zhu Date: Mon, 3 Nov 2014 15:28:38 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > Hello, > > I did some work similar to this. > Please reference following links. > > https://lkml.org/lkml/2014/5/28/64 > https://lkml.org/lkml/2014/5/28/57 > I tested #1 approach and found the problem. Although free memory on > meminfo can move around low watermark, there is large fluctuation on free > memory, because too many pages are reclaimed when kswapd is invoked. > Reason for this behaviour is that successive allocated CMA pages are > on the LRU list in that order and kswapd reclaim them in same order. > These memory doesn't help watermark checking from kwapd, so too many > pages are reclaimed, I guess. This issue can be handle with some change around shrink code. I am trying to integrate a patch for them. But I am not sure we met the same issue. Do you mind give me more info about this part? > > And, aggressive allocation should be postponed until freepage counting > bug is fixed, because aggressive allocation enlarge the possiblity > of problem occurence. I tried to fix that bug, too. See following link. > > https://lkml.org/lkml/2014/10/23/90 I am following these patches. They are great! Thanks for your work. Best, Hui > > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id CFE556B00DB for ; Mon, 3 Nov 2014 03:04:13 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id lj1so11670499pab.36 for ; Mon, 03 Nov 2014 00:04:13 -0800 (PST) Received: from lgemrelse6q.lge.com (LGEMRELSE6Q.lge.com. [156.147.1.121]) by mx.google.com with ESMTP id z12si14856202pdi.23.2014.11.03.00.04.10 for ; Mon, 03 Nov 2014 00:04:12 -0800 (PST) Date: Mon, 3 Nov 2014 17:05:46 +0900 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141103080546.GB7052@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > >> MIGRATE_MOVABLE. > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > >> order that Linux kernel want. > >> > >> If a system that has a lot of user space program is running, for > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > >> allocated. Before function __rmqueue_fallback get memory from > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > >> kernel kill some tasks to release memory. > >> > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > >> be more aggressive about allocation. > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > >> doesn't have enough pages for allocation, go back to allocate memory from > >> MIGRATE_MOVABLE. > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > Hello, > > > > I did some work similar to this. > > Please reference following links. > > > > https://lkml.org/lkml/2014/5/28/64 > > https://lkml.org/lkml/2014/5/28/57 > > > I tested #1 approach and found the problem. Although free memory on > > meminfo can move around low watermark, there is large fluctuation on free > > memory, because too many pages are reclaimed when kswapd is invoked. > > Reason for this behaviour is that successive allocated CMA pages are > > on the LRU list in that order and kswapd reclaim them in same order. > > These memory doesn't help watermark checking from kwapd, so too many > > pages are reclaimed, I guess. > > This issue can be handle with some change around shrink code. I am > trying to integrate a patch for them. > But I am not sure we met the same issue. Do you mind give me more > info about this part? I forgot the issue because there is so big time-gap. I need sometime to bring issue back to my brain. I will answer it soon after some thinking. > > > > > And, aggressive allocation should be postponed until freepage counting > > bug is fixed, because aggressive allocation enlarge the possiblity > > of problem occurence. I tried to fix that bug, too. See following link. > > > > https://lkml.org/lkml/2014/10/23/90 > > I am following these patches. They are great! Thanks for your work. Thanks. :) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by kanga.kvack.org (Postfix) with ESMTP id 20FB76B010A for ; Mon, 3 Nov 2014 03:47:05 -0500 (EST) Received: by mail-ob0-f172.google.com with SMTP id wp4so8725114obc.3 for ; Mon, 03 Nov 2014 00:47:04 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com. [2607:f8b0:4003:c06::232]) by mx.google.com with ESMTPS id t2si17900089obo.39.2014.11.03.00.47.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 00:47:03 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id v63so5011078oia.9 for ; Mon, 03 Nov 2014 00:47:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <5450FD15.4000708@suse.cz> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> From: Hui Zhu Date: Mon, 3 Nov 2014 16:46:23 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka , iamjoonsoo.kim@lge.com Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Wed, Oct 29, 2014 at 10:43 PM, 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 > - it's more complex, but I guess we have most of the necessary > infrastructure in compaction already :) I think this idea make CMA allocation part become complex but make balance and shrink code become easy because it make CMA become real memory. I just worry about the speed of migrate memory with this idea. :) Thanks, Hui > > Thoughts? > Vlastimil > >> Thanks, >> Laura >> > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by kanga.kvack.org (Postfix) with ESMTP id ED4AD6B0071 for ; Mon, 3 Nov 2014 21:29:31 -0500 (EST) Received: by mail-pa0-f50.google.com with SMTP id eu11so13415371pac.37 for ; Mon, 03 Nov 2014 18:29:31 -0800 (PST) Received: from lgemrelse6q.lge.com (LGEMRELSE6Q.lge.com. [156.147.1.121]) by mx.google.com with ESMTP id kr5si16693115pdb.231.2014.11.03.18.29.29 for ; Mon, 03 Nov 2014 18:29:30 -0800 (PST) Date: Tue, 4 Nov 2014 11:31:12 +0900 From: Joonsoo Kim Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141104023112.GA17804@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> <20141103080546.GB7052@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103080546.GB7052@js1304-P5Q-DELUXE> Sender: owner-linux-mm@kvack.org List-ID: To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Mon, Nov 03, 2014 at 05:05:46PM +0900, Joonsoo Kim wrote: > On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > > >> MIGRATE_MOVABLE. > > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > > >> order that Linux kernel want. > > >> > > >> If a system that has a lot of user space program is running, for > > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > > >> allocated. Before function __rmqueue_fallback get memory from > > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > > >> kernel kill some tasks to release memory. > > >> > > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > > >> be more aggressive about allocation. > > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > > >> doesn't have enough pages for allocation, go back to allocate memory from > > >> MIGRATE_MOVABLE. > > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > > > Hello, > > > > > > I did some work similar to this. > > > Please reference following links. > > > > > > https://lkml.org/lkml/2014/5/28/64 > > > https://lkml.org/lkml/2014/5/28/57 > > > > > I tested #1 approach and found the problem. Although free memory on > > > meminfo can move around low watermark, there is large fluctuation on free > > > memory, because too many pages are reclaimed when kswapd is invoked. > > > Reason for this behaviour is that successive allocated CMA pages are > > > on the LRU list in that order and kswapd reclaim them in same order. > > > These memory doesn't help watermark checking from kwapd, so too many > > > pages are reclaimed, I guess. > > > > This issue can be handle with some change around shrink code. I am > > trying to integrate a patch for them. > > But I am not sure we met the same issue. Do you mind give me more > > info about this part? > > I forgot the issue because there is so big time-gap. I need sometime > to bring issue back to my brain. I will answer it soon after some thinking. Hello, Yes, the issue I mentioned before can be handled by modifying shrink code. I didn't dive into the problem so I also didn't know the detail. What I know is that there is large fluctuation on memory statistics and my guess is that it is caused by order of reclaimable pages. If we use #1 approach, the bulk of cma pages used for page cache or something are linked together and will be reclaimed all at once, because reclaiming cma pages are not counted and watermark check still fails until normal pages are reclaimed. I think that round-robin approach is better. Reasons are on the following: 1) Want to spread CMA freepages to whole users, not specific one user. We can modify shirnk code not to reclaim pages on CMA, because it doesn't help watermark checking in some cases. In this case, if we don't use round-robin, one specific user whose mapping with CMA pages can get all the benefit. Others would take all the overhead. I think that spreading will make all users fair. 2) Using CMA freepages first needlessly imposes overhead to CMA user. If the system has enough normal freepages, it is better not to use it as much as possible. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by kanga.kvack.org (Postfix) with ESMTP id CEB016B00E0 for ; Tue, 4 Nov 2014 04:00:06 -0500 (EST) Received: by mail-oi0-f54.google.com with SMTP id a141so8289547oig.41 for ; Tue, 04 Nov 2014 01:00:06 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com. [2607:f8b0:4003:c06::233]) by mx.google.com with ESMTPS id e3si20714896obh.37.2014.11.04.01.00.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 01:00:05 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id g201so10091913oib.10 for ; Tue, 04 Nov 2014 01:00:04 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20141104075330.GB23102@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> From: Hui Zhu Date: Tue, 4 Nov 2014 16:59:24 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Vlastimil Babka , Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Tue, Nov 4, 2014 at 3:53 PM, Minchan Kim wrote: > 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. Thanks. > > 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. Even if kernel use it to allocate the CMA memory, CMA alloc latency will happen if most of memory is allocated and driver try to get CMA memory. https://lkml.org/lkml/2014/10/17/129 https://lkml.org/lkml/2014/10/17/130 These patches let cma_alloc do a shrink with function shrink_all_memory_for_cma if need. It handle a lot of latency issue in my part. And I think it can be more configurable for example some device use it and others not. Thanks, Hui > >> >> Thoughts? >> Vlastimil >> >> >Thanks, >> >Laura >> > >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email@kvack.org > > -- > Kind regards, > Minchan Kim > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by kanga.kvack.org (Postfix) with ESMTP id 5B0016B0069 for ; Thu, 27 Nov 2014 22:45:47 -0500 (EST) Received: by mail-ob0-f172.google.com with SMTP id wn1so4508977obc.3 for ; Thu, 27 Nov 2014 19:45:47 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com. [2607:f8b0:4003:c06::22a]) by mx.google.com with ESMTPS id nr7si4210135oeb.98.2014.11.27.19.45.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 19:45:45 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id v63so4228729oia.1 for ; Thu, 27 Nov 2014 19:45:45 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20141024052849.GF15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> <20141024052849.GF15243@js1304-P5Q-DELUXE> From: Hui Zhu Date: Fri, 28 Nov 2014 11:45:04 +0800 Message-ID: Subject: Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org On Fri, Oct 24, 2014 at 1:28 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote: >> If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and >> conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) >> allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. >> >> Signed-off-by: Hui Zhu >> --- >> mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- >> 1 file changed, 31 insertions(+), 11 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 736d8e1..87bc326 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -65,6 +65,10 @@ >> #include >> #include "internal.h" >> >> +#ifdef CONFIG_CMA_AGGRESSIVE >> +#include >> +#endif >> + >> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ >> static DEFINE_MUTEX(pcp_batch_high_lock); >> #define MIN_PERCPU_PAGELIST_FRACTION (8) >> @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, >> { >> struct page *page; >> >> -retry_reserve: >> +#ifdef CONFIG_CMA_AGGRESSIVE >> + if (cma_aggressive_switch >> + && migratetype == MIGRATE_MOVABLE >> + && atomic_read(&cma_alloc_counter) == 0 >> + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min >> + + (1 << order)) >> + migratetype = MIGRATE_CMA; >> +#endif >> +retry: > > I don't get it why cma_alloc_counter should be tested. > When cma alloc is progress, pageblock is isolated so that pages on that > pageblock cannot be allocated. Why should we prevent aggressive > allocation in this case? > Hi Joonsoo, Even if the pageblock is isolated in the begin of function alloc_contig_range, it will unisolate if alloc_contig_range get some error for example "PFNs busy". And the cma_alloc will keep call alloc_contig_range with another address if need. So it will decrease the contradiction between CMA allocation in cma_alloc and __rmqueue with cma_alloc_counter. Thanks, Hui > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751383AbaJPDgU (ORCPT ); Wed, 15 Oct 2014 23:36:20 -0400 Received: from [42.62.48.242] ([42.62.48.242]:7234 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750993AbaJPDgR (ORCPT ); Wed, 15 Oct 2014 23:36:17 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Date: Thu, 16 Oct 2014 11:35:48 +0800 Message-ID: <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK that depend on CMA_AGGRESSIVE. If physical memory size (not include CMA memory) in byte less than or equal to CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) will be opened. When system boot, this value will set to sysctl "vm.cma-aggressive-free-min". If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will be set to true when Linux boot. Signed-off-by: Hui Zhu --- mm/Kconfig | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 1d1ae6b..940f5f3 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -527,6 +527,49 @@ config CMA_AREAS If unsure, leave the default value "7". +config CMA_AGGRESSIVE + bool "CMA aggressive" + depends on CMA + default n + help + Be more aggressive about taking memory from CMA when allocate MOVABLE + page. + Sysctl "vm.cma-aggressive-switch", "vm.cma-aggressive-alloc-max" + and "vm.cma-aggressive-shrink-switch" can control this function. + If unsure, say "n". + +config CMA_AGGRESSIVE_PHY_MAX + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" + depends on CMA_AGGRESSIVE + default 0x40000000 + help + If physical memory size (not include CMA memory) in byte less than or + equal to this value, CMA aggressive switch will be opened. + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control + the CMA AGGRESSIVE switch. + +config CMA_AGGRESSIVE_FREE_MIN + int "The minimum free CMA page number that CMA aggressive work" + depends on CMA_AGGRESSIVE + default 500 + help + When system boot, this value will set to sysctl + "vm.cma-aggressive-free-min". + If the number of CMA free pages is small than this sysctl value, + CMA aggressive will not work. + +config CMA_AGGRESSIVE_SHRINK + bool "CMA aggressive shrink" + depends on CMA_AGGRESSIVE + default y + help + If this value is true, sysctl "vm.cma-aggressive-shrink-switch" will + be set to true when Linux boot. + If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal + memory's size is smaller than the size that it want to allocate, + do memory shrink before driver allocate pages from CMA. + If unsure, say "y". + config MEM_SOFT_DIRTY bool "Track memory changes" depends on CHECKPOINT_RESTORE && HAVE_ARCH_SOFT_DIRTY && PROC_FS -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751476AbaJPDgl (ORCPT ); Wed, 15 Oct 2014 23:36:41 -0400 Received: from [42.62.48.242] ([42.62.48.242]:7234 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751325AbaJPDgT (ORCPT ); Wed, 15 Oct 2014 23:36:19 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Date: Thu, 16 Oct 2014 11:35:51 +0800 Message-ID: <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. Signed-off-by: Hui Zhu --- mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 736d8e1..87bc326 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -65,6 +65,10 @@ #include #include "internal.h" +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ static DEFINE_MUTEX(pcp_batch_high_lock); #define MIN_PERCPU_PAGELIST_FRACTION (8) @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, { struct page *page; -retry_reserve: +#ifdef CONFIG_CMA_AGGRESSIVE + if (cma_aggressive_switch + && migratetype == MIGRATE_MOVABLE + && atomic_read(&cma_alloc_counter) == 0 + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min + + (1 << order)) + migratetype = MIGRATE_CMA; +#endif +retry: page = __rmqueue_smallest(zone, order, migratetype); - if (unlikely(!page) && migratetype != MIGRATE_RESERVE) { - page = __rmqueue_fallback(zone, order, migratetype); + if (unlikely(!page)) { +#ifdef CONFIG_CMA_AGGRESSIVE + if (migratetype == MIGRATE_CMA) { + migratetype = MIGRATE_MOVABLE; + goto retry; + } +#endif + if (migratetype != MIGRATE_RESERVE) { + page = __rmqueue_fallback(zone, order, migratetype); - /* - * Use MIGRATE_RESERVE rather than fail an allocation. goto - * is used because __rmqueue_smallest is an inline function - * and we want just one call site - */ - if (!page) { - migratetype = MIGRATE_RESERVE; - goto retry_reserve; + /* + * Use MIGRATE_RESERVE rather than fail an allocation. + * goto is used because __rmqueue_smallest is an inline + * function and we want just one call site + */ + if (!page) { + migratetype = MIGRATE_RESERVE; + goto retry; + } } } -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751433AbaJPDgV (ORCPT ); Wed, 15 Oct 2014 23:36:21 -0400 Received: from [42.62.48.242] ([42.62.48.242]:15935 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751073AbaJPDgS (ORCPT ); Wed, 15 Oct 2014 23:36:18 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Thu, 16 Oct 2014 11:35:49 +0800 Message-ID: <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Function shrink_all_memory try to free `nr_to_reclaim' of memory. CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of memory. It need different scan_control with current caller function hibernate_preallocate_memory. If hibernation is true, the caller is hibernate_preallocate_memory. if not, the caller is CMA alloc function. Signed-off-by: Hui Zhu --- include/linux/swap.h | 3 ++- kernel/power/snapshot.c | 2 +- mm/vmscan.c | 19 +++++++++++++------ 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/include/linux/swap.h b/include/linux/swap.h index 37a585b..9f2cb43 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, gfp_t gfp_mask, bool noswap, struct zone *zone, unsigned long *nr_scanned); -extern unsigned long shrink_all_memory(unsigned long nr_pages); +extern unsigned long shrink_all_memory(unsigned long nr_pages, + bool hibernation); extern int vm_swappiness; extern int remove_mapping(struct address_space *mapping, struct page *page); extern unsigned long vm_total_pages; diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 791a618..a00fc35 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) * NOTE: If this is not done, performance will be hurt badly in some * test cases. */ - shrink_all_memory(saveable - size); + shrink_all_memory(saveable - size, true); /* * The number of saveable pages in memory was too high, so apply some diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..fdcfa30 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } -#ifdef CONFIG_HIBERNATION +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of * freed pages. @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) * LRU order by reclaiming preferentially * inactive > active > active referenced > active mapped */ -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) { struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, - .gfp_mask = GFP_HIGHUSER_MOVABLE, .priority = DEF_PRIORITY, - .may_writepage = 1, .may_unmap = 1, .may_swap = 1, - .hibernation_mode = 1, }; struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); struct task_struct *p = current; unsigned long nr_reclaimed; + if (hibernation) { + sc.hibernation_mode = 1; + sc.may_writepage = 1; + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; + } else { + sc.hibernation_mode = 0; + sc.may_writepage = !laptop_mode; + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; + } + p->flags |= PF_MEMALLOC; lockdep_set_current_reclaim_state(sc.gfp_mask); reclaim_state.reclaimed_slab = 0; @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) return nr_reclaimed; } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751526AbaJPDgz (ORCPT ); Wed, 15 Oct 2014 23:36:55 -0400 Received: from [42.62.48.242] ([42.62.48.242]:7249 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751287AbaJPDgT (ORCPT ); Wed, 15 Oct 2014 23:36:19 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Date: Thu, 16 Oct 2014 11:35:50 +0800 Message-ID: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and cma_aggressive_shrink_switch. cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be controlled by sysctl vm.cma-aggressive-switch. cma_aggressive_free_min can be controlled by sysctl "vm.cma-aggressive-free-min". If the number of CMA free pages is small than this sysctl value, CMA_AGGRESSIVE will not work in page alloc code. cma_aggressive_shrink_switch can be controlled by sysctl "vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal memory's size is smaller than the size that it want to allocate, do memory shrink with function shrink_all_memory before driver allocate pages from CMA. When Linux kernel try to reserve custom contiguous area, increase the value of cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code. After reserve custom contiguous area function return, decreases the value of cma_alloc_counter. Signed-off-by: Hui Zhu --- include/linux/cma.h | 7 +++++++ kernel/sysctl.c | 27 +++++++++++++++++++++++++++ mm/cma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) diff --git a/include/linux/cma.h b/include/linux/cma.h index 0430ed0..df96abf 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -15,6 +15,13 @@ struct cma; +#ifdef CONFIG_CMA_AGGRESSIVE +extern atomic_t cma_alloc_counter; +extern int cma_aggressive_switch; +extern unsigned long cma_aggressive_free_min; +extern int cma_aggressive_shrink_switch; +#endif + extern phys_addr_t cma_get_base(struct cma *cma); extern unsigned long cma_get_size(struct cma *cma); diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 4aada6d..646929e2 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -92,6 +92,10 @@ #include #endif +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + #if defined(CONFIG_SYSCTL) @@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_CMA_AGGRESSIVE + { + .procname = "cma-aggressive-switch", + .data = &cma_aggressive_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, + { + .procname = "cma-aggressive-free-min", + .data = &cma_aggressive_free_min, + .maxlen = sizeof(unsigned long), + .mode = 0600, + .proc_handler = proc_doulongvec_minmax, + }, + { + .procname = "cma-aggressive-shrink-switch", + .data = &cma_aggressive_shrink_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, +#endif { } }; diff --git a/mm/cma.c b/mm/cma.c index 963bc4a..566ed5f 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -33,6 +33,7 @@ #include #include #include +#include struct cma { unsigned long base_pfn; @@ -127,6 +128,27 @@ err: return -EINVAL; } +#ifdef CONFIG_CMA_AGGRESSIVE +/* The counter for the dma_alloc_from_contiguous and + dma_release_from_contiguous. */ +atomic_t cma_alloc_counter = ATOMIC_INIT(0); + +/* Swich of CMA_AGGRESSIVE. */ +int cma_aggressive_switch __read_mostly; + +/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE will + not work. */ +#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN +unsigned long cma_aggressive_free_min __read_mostly = + CONFIG_CMA_AGGRESSIVE_FREE_MIN; +#else +unsigned long cma_aggressive_free_min __read_mostly = 500; +#endif + +/* Swich of CMA_AGGRESSIVE shink. */ +int cma_aggressive_shrink_switch __read_mostly; +#endif + static int __init cma_init_reserved_areas(void) { int i; @@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void) return ret; } +#ifdef CONFIG_CMA_AGGRESSIVE + cma_aggressive_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX + if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX) +#else + if (memblock_phys_mem_size() <= 0x40000000) +#endif + cma_aggressive_switch = 1; + + cma_aggressive_shrink_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK + if (cma_aggressive_switch) + cma_aggressive_shrink_switch = 1; +#endif +#endif + return 0; } core_initcall(cma_init_reserved_areas); @@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) unsigned long bitmap_maxno, bitmap_no, bitmap_count; struct page *page = NULL; int ret; +#ifdef CONFIG_CMA_AGGRESSIVE + int free = global_page_state(NR_FREE_PAGES) + - global_page_state(NR_FREE_CMA_PAGES) + - totalreserve_pages; +#endif if (!cma || !cma->count) return NULL; @@ -326,6 +369,13 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) bitmap_maxno = cma_bitmap_maxno(cma); bitmap_count = cma_bitmap_pages_to_bits(cma, count); +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_inc(&cma_alloc_counter); + if (cma_aggressive_switch && cma_aggressive_shrink_switch + && free < count) + shrink_all_memory(count - free, false); +#endif + for (;;) { mutex_lock(&cma->lock); bitmap_no = bitmap_find_next_zero_area(cma->bitmap, @@ -361,6 +411,10 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) start = bitmap_no + mask + 1; } +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_dec(&cma_alloc_counter); +#endif + pr_debug("%s(): returned %p\n", __func__, page); return page; } -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751328AbaJPDgS (ORCPT ); Wed, 15 Oct 2014 23:36:18 -0400 Received: from [42.62.48.242] ([42.62.48.242]:15935 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750969AbaJPDgR (ORCPT ); Wed, 15 Oct 2014 23:36:17 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Date: Thu, 16 Oct 2014 11:35:47 +0800 Message-ID: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of MIGRATE_MOVABLE. MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in order that Linux kernel want. If a system that has a lot of user space program is running, for instance, an Android board, most of memory is in MIGRATE_MOVABLE and allocated. Before function __rmqueue_fallback get memory from MIGRATE_CMA, the oom_killer will kill a task to release memory when kernel want get MIGRATE_UNMOVABLE memory because fallbacks of MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. This status is odd. The MIGRATE_CMA has a lot free memory but Linux kernel kill some tasks to release memory. This patch series adds a new function CMA_AGGRESSIVE to make CMA memory be more aggressive about allocation. If function CMA_AGGRESSIVE is available, when Linux kernel call function __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA doesn't have enough pages for allocation, go back to allocate memory from MIGRATE_MOVABLE. Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751239AbaJPFOA (ORCPT ); Thu, 16 Oct 2014 01:14:00 -0400 Received: from mail-ie0-f178.google.com ([209.85.223.178]:46738 "EHLO mail-ie0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbaJPFN6 (ORCPT ); Thu, 16 Oct 2014 01:13:58 -0400 MIME-Version: 1.0 In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Date: Thu, 16 Oct 2014 13:13:57 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation From: Weijie Yang To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 16, 2014 at 11:35 AM, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. I'm not very clear to this description, what issue do you try to solve? Make MIGRATE_CMA be the fallback of desired MIGRATE_UNMOVABLE? > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. I don't think so. That will cause MIGRATE_CMA depleted prematurely, and when a user(such as camera) wants CMA memory, he will not get the wanted memory. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. I don't think this is the root cause of oom. But I am interested in the CMA shrinker idea, I will follow this mail. Thanks for your work, add some test data will be better. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751608AbaJPIZH (ORCPT ); Thu, 16 Oct 2014 04:25:07 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:64130 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750816AbaJPIZD (ORCPT ); Thu, 16 Oct 2014 04:25:03 -0400 From: "Rafael J. Wysocki" To: Hui Zhu Cc: m.szyprowski@samsung.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Date: Thu, 16 Oct 2014 10:45:21 +0200 Message-ID: <1471435.6q4YYkTopF@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [CC list trimmed] On Thursday, October 16, 2014 11:35:49 AM Hui Zhu wrote: > Function shrink_all_memory try to free `nr_to_reclaim' of memory. > CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of > memory. It need different scan_control with current caller function > hibernate_preallocate_memory. > > If hibernation is true, the caller is hibernate_preallocate_memory. > if not, the caller is CMA alloc function. > > Signed-off-by: Hui Zhu > --- > include/linux/swap.h | 3 ++- > kernel/power/snapshot.c | 2 +- > mm/vmscan.c | 19 +++++++++++++------ > 3 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/include/linux/swap.h b/include/linux/swap.h > index 37a585b..9f2cb43 100644 > --- a/include/linux/swap.h > +++ b/include/linux/swap.h > @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, > gfp_t gfp_mask, bool noswap, > struct zone *zone, > unsigned long *nr_scanned); > -extern unsigned long shrink_all_memory(unsigned long nr_pages); > +extern unsigned long shrink_all_memory(unsigned long nr_pages, > + bool hibernation); > extern int vm_swappiness; > extern int remove_mapping(struct address_space *mapping, struct page *page); > extern unsigned long vm_total_pages; > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c > index 791a618..a00fc35 100644 > --- a/kernel/power/snapshot.c > +++ b/kernel/power/snapshot.c > @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) > * NOTE: If this is not done, performance will be hurt badly in some > * test cases. > */ > - shrink_all_memory(saveable - size); > + shrink_all_memory(saveable - size, true); Instead of doing this, can you please define __shrink_all_memory() that will take the appropriate struct scan_control as an argument and then define two wrappers around that, one for hibernation and one for CMA? The way you did it opens a field for bugs caused by passing a wrong value as the second argument. > > /* > * The number of saveable pages in memory was too high, so apply some > diff --git a/mm/vmscan.c b/mm/vmscan.c > index dcb4707..fdcfa30 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) > wake_up_interruptible(&pgdat->kswapd_wait); > } > > -#ifdef CONFIG_HIBERNATION > +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE > /* > * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of > * freed pages. > @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) > * LRU order by reclaiming preferentially > * inactive > active > active referenced > active mapped > */ > -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) > +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) > { > struct reclaim_state reclaim_state; > struct scan_control sc = { > .nr_to_reclaim = nr_to_reclaim, > - .gfp_mask = GFP_HIGHUSER_MOVABLE, > .priority = DEF_PRIORITY, > - .may_writepage = 1, > .may_unmap = 1, > .may_swap = 1, > - .hibernation_mode = 1, > }; > struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); > struct task_struct *p = current; > unsigned long nr_reclaimed; > > + if (hibernation) { > + sc.hibernation_mode = 1; > + sc.may_writepage = 1; > + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; > + } else { > + sc.hibernation_mode = 0; > + sc.may_writepage = !laptop_mode; > + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; > + } > + > p->flags |= PF_MEMALLOC; > lockdep_set_current_reclaim_state(sc.gfp_mask); > reclaim_state.reclaimed_slab = 0; > @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) > > return nr_reclaimed; > } > -#endif /* CONFIG_HIBERNATION */ > +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ > > /* It's optimal to keep kswapds on the same CPUs as their memory, but > not required for correctness. So if the last cpu in a node goes > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751287AbaJPI4A (ORCPT ); Thu, 16 Oct 2014 04:56:00 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:48850 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750816AbaJPIz5 (ORCPT ); Thu, 16 Oct 2014 04:55:57 -0400 Message-ID: <543F8812.2020002@codeaurora.org> Date: Thu, 16 Oct 2014 01:55:46 -0700 From: Laura Abbott User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com CC: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> In-Reply-To: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/15/2014 8:35 PM, Hui Zhu wrote: > In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > MIGRATE_MOVABLE. > MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > order that Linux kernel want. > > If a system that has a lot of user space program is running, for > instance, an Android board, most of memory is in MIGRATE_MOVABLE and > allocated. Before function __rmqueue_fallback get memory from > MIGRATE_CMA, the oom_killer will kill a task to release memory when > kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > This status is odd. The MIGRATE_CMA has a lot free memory but Linux > kernel kill some tasks to release memory. > > This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > be more aggressive about allocation. > If function CMA_AGGRESSIVE is available, when Linux kernel call function > __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > doesn't have enough pages for allocation, go back to allocate memory from > MIGRATE_MOVABLE. > Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > 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. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753269AbaJQGS4 (ORCPT ); Fri, 17 Oct 2014 02:18:56 -0400 Received: from [42.62.48.242] ([42.62.48.242]:7204 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750729AbaJQGSz (ORCPT ); Fri, 17 Oct 2014 02:18:55 -0400 From: =?gb2312?B?1uy71A==?= To: "Rafael J. Wysocki" CC: "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Thread-Topic: [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Thread-Index: AQHP6PJVzwc7eQGqjUqsqpyi3U8pHQ== Date: Fri, 17 Oct 2014 06:18:39 +0000 Message-ID: <70d41b6fdea74d5fb88f314708879acc@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-3-git-send-email-zhuhui@xiaomi.com> <1471435.6q4YYkTopF@vostro.rjw.lan> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.37.216.50] Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id s9H6J1lq009602 On 10/16/14 16:29, Rafael J. Wysocki wrote: > [CC list trimmed] > > On Thursday, October 16, 2014 11:35:49 AM Hui Zhu wrote: >> Function shrink_all_memory try to free `nr_to_reclaim' of memory. >> CMA_AGGRESSIVE_SHRINK function will call this functon to free `nr_to_reclaim' of >> memory. It need different scan_control with current caller function >> hibernate_preallocate_memory. >> >> If hibernation is true, the caller is hibernate_preallocate_memory. >> if not, the caller is CMA alloc function. >> >> Signed-off-by: Hui Zhu >> --- >> include/linux/swap.h | 3 ++- >> kernel/power/snapshot.c | 2 +- >> mm/vmscan.c | 19 +++++++++++++------ >> 3 files changed, 16 insertions(+), 8 deletions(-) >> >> diff --git a/include/linux/swap.h b/include/linux/swap.h >> index 37a585b..9f2cb43 100644 >> --- a/include/linux/swap.h >> +++ b/include/linux/swap.h >> @@ -335,7 +335,8 @@ extern unsigned long mem_cgroup_shrink_node_zone(struct mem_cgroup *mem, >> gfp_t gfp_mask, bool noswap, >> struct zone *zone, >> unsigned long *nr_scanned); >> -extern unsigned long shrink_all_memory(unsigned long nr_pages); >> +extern unsigned long shrink_all_memory(unsigned long nr_pages, >> + bool hibernation); >> extern int vm_swappiness; >> extern int remove_mapping(struct address_space *mapping, struct page *page); >> extern unsigned long vm_total_pages; >> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c >> index 791a618..a00fc35 100644 >> --- a/kernel/power/snapshot.c >> +++ b/kernel/power/snapshot.c >> @@ -1657,7 +1657,7 @@ int hibernate_preallocate_memory(void) >> * NOTE: If this is not done, performance will be hurt badly in some >> * test cases. >> */ >> - shrink_all_memory(saveable - size); >> + shrink_all_memory(saveable - size, true); > > Instead of doing this, can you please define > > __shrink_all_memory() > > that will take the appropriate struct scan_control as an argument and > then define two wrappers around that, one for hibernation and one for CMA? > > The way you did it opens a field for bugs caused by passing a wrong value > as the second argument. Thanks Rafael. I will update patch according to your comments. Best, Hui > >> >> /* >> * The number of saveable pages in memory was too high, so apply some >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index dcb4707..fdcfa30 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -3404,7 +3404,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) >> wake_up_interruptible(&pgdat->kswapd_wait); >> } >> >> -#ifdef CONFIG_HIBERNATION >> +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE >> /* >> * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of >> * freed pages. >> @@ -3413,22 +3413,29 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) >> * LRU order by reclaiming preferentially >> * inactive > active > active referenced > active mapped >> */ >> -unsigned long shrink_all_memory(unsigned long nr_to_reclaim) >> +unsigned long shrink_all_memory(unsigned long nr_to_reclaim, bool hibernation) >> { >> struct reclaim_state reclaim_state; >> struct scan_control sc = { >> .nr_to_reclaim = nr_to_reclaim, >> - .gfp_mask = GFP_HIGHUSER_MOVABLE, >> .priority = DEF_PRIORITY, >> - .may_writepage = 1, >> .may_unmap = 1, >> .may_swap = 1, >> - .hibernation_mode = 1, >> }; >> struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); >> struct task_struct *p = current; >> unsigned long nr_reclaimed; >> >> + if (hibernation) { >> + sc.hibernation_mode = 1; >> + sc.may_writepage = 1; >> + sc.gfp_mask = GFP_HIGHUSER_MOVABLE; >> + } else { >> + sc.hibernation_mode = 0; >> + sc.may_writepage = !laptop_mode; >> + sc.gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM; >> + } >> + >> p->flags |= PF_MEMALLOC; >> lockdep_set_current_reclaim_state(sc.gfp_mask); >> reclaim_state.reclaimed_slab = 0; >> @@ -3442,7 +3449,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) >> >> return nr_reclaimed; >> } >> -#endif /* CONFIG_HIBERNATION */ >> +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ >> >> /* It's optimal to keep kswapds on the same CPUs as their memory, but >> not required for correctness. So if the last cpu in a node goes >> > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753418AbaJQHpW (ORCPT ); Fri, 17 Oct 2014 03:45:22 -0400 Received: from [42.62.48.242] ([42.62.48.242]:63453 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751403AbaJQHpU (ORCPT ); Fri, 17 Oct 2014 03:45:20 -0400 From: =?gb2312?B?1uy71A==?= To: Laura Abbott , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "akinobu.mita@gmail.com" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" CC: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Thread-Topic: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Thread-Index: AQHP6PJVOSZsZeZKBkSR9KhOfKwh0g== Date: Fri, 17 Oct 2014 07:44:26 +0000 Message-ID: References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.37.216.50] x-esetresult: clean, is OK x-esetid: 16754838BAB46B0E423415 Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id s9H7jRFs009866 On 10/16/14 16:56, Laura Abbott wrote: > On 10/15/2014 8:35 PM, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. >> > > It's good to see another proposal to fix CMA utilization. Thanks Laura. 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. I did some test with the cma_alloc_counter and cma-aggressive-shrink in a android board that has 1g memory. Run some apps to make free CMA close to the value of cma_aggressive_free_min(500 pages). A driver Begin to request CMA more than 10 times. Each time, it will request more than 3000 pages. I don't have established number for that because it is really hard to get a fail. I think the success rate is over 95% at least. And I think maybe the isolate fail has relation with page alloc and free code. Maybe let zone->lock protect more code can handle this issue. Thanks, Hui > > Thanks, > Laura > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751641AbaJQJ2v (ORCPT ); Fri, 17 Oct 2014 05:28:51 -0400 Received: from [42.62.48.242] ([42.62.48.242]:4613 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751459AbaJQJ2t (ORCPT ); Fri, 17 Oct 2014 05:28:49 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma Date: Fri, 17 Oct 2014 17:28:04 +0800 Message-ID: <1413538084-15743-1-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1471435.6q4YYkTopF@vostro.rjw.lan> References: <1471435.6q4YYkTopF@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3615 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update this patch according to the comments from Rafael. Function shrink_all_memory_for_cma try to free `nr_to_reclaim' of memory. CMA aggressive shrink function will call this functon to free `nr_to_reclaim' of memory. Signed-off-by: Hui Zhu --- mm/vmscan.c | 58 +++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dcb4707..658dc8d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3404,6 +3404,28 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) wake_up_interruptible(&pgdat->kswapd_wait); } +#if defined CONFIG_HIBERNATION || defined CONFIG_CMA_AGGRESSIVE +static unsigned long __shrink_all_memory(struct scan_control *sc) +{ + struct reclaim_state reclaim_state; + struct zonelist *zonelist = node_zonelist(numa_node_id(), sc->gfp_mask); + struct task_struct *p = current; + unsigned long nr_reclaimed; + + p->flags |= PF_MEMALLOC; + lockdep_set_current_reclaim_state(sc->gfp_mask); + reclaim_state.reclaimed_slab = 0; + p->reclaim_state = &reclaim_state; + + nr_reclaimed = do_try_to_free_pages(zonelist, sc); + + p->reclaim_state = NULL; + lockdep_clear_current_reclaim_state(); + p->flags &= ~PF_MEMALLOC; + + return nr_reclaimed; +} + #ifdef CONFIG_HIBERNATION /* * Try to free `nr_to_reclaim' of memory, system-wide, and return the number of @@ -3415,7 +3437,6 @@ void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx) */ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) { - struct reclaim_state reclaim_state; struct scan_control sc = { .nr_to_reclaim = nr_to_reclaim, .gfp_mask = GFP_HIGHUSER_MOVABLE, @@ -3425,24 +3446,31 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) .may_swap = 1, .hibernation_mode = 1, }; - struct zonelist *zonelist = node_zonelist(numa_node_id(), sc.gfp_mask); - struct task_struct *p = current; - unsigned long nr_reclaimed; - - p->flags |= PF_MEMALLOC; - lockdep_set_current_reclaim_state(sc.gfp_mask); - reclaim_state.reclaimed_slab = 0; - p->reclaim_state = &reclaim_state; - nr_reclaimed = do_try_to_free_pages(zonelist, &sc); + return __shrink_all_memory(&sc); +} +#endif /* CONFIG_HIBERNATION */ - p->reclaim_state = NULL; - lockdep_clear_current_reclaim_state(); - p->flags &= ~PF_MEMALLOC; +#ifdef CONFIG_CMA_AGGRESSIVE +/* + * Try to free `nr_to_reclaim' of memory, system-wide, for CMA aggressive + * shrink function. + */ +void shrink_all_memory_for_cma(unsigned long nr_to_reclaim) +{ + struct scan_control sc = { + .nr_to_reclaim = nr_to_reclaim, + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_HIGHMEM, + .priority = DEF_PRIORITY, + .may_writepage = !laptop_mode, + .may_unmap = 1, + .may_swap = 1, + }; - return nr_reclaimed; + __shrink_all_memory(&sc); } -#endif /* CONFIG_HIBERNATION */ +#endif /* CONFIG_CMA_AGGRESSIVE */ +#endif /* CONFIG_HIBERNATION || CONFIG_CMA_AGGRESSIVE */ /* It's optimal to keep kswapds on the same CPUs as their memory, but not required for correctness. So if the last cpu in a node goes -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751706AbaJQJaP (ORCPT ); Fri, 17 Oct 2014 05:30:15 -0400 Received: from [42.62.48.242] ([42.62.48.242]:51003 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750828AbaJQJaN (ORCPT ); Fri, 17 Oct 2014 05:30:13 -0400 From: Hui Zhu To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , , , Hui Zhu Subject: [PATCH v2 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Date: Fri, 17 Oct 2014 17:30:05 +0800 Message-ID: <1413538205-15915-1-git-send-email-zhuhui@xiaomi.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> References: <1413430551-22392-4-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [172.27.14.101] X-ClientProxiedBy: CNCAS1.mioffice.cn (10.237.8.131) To cnbox4.mioffice.cn (10.237.8.144) X-EsetResult: clean, is OK X-EsetId: 587748382C4597170C3615 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update this patch according to the comments from Rafael. Add cma_alloc_counter, cma_aggressive_switch, cma_aggressive_free_min and cma_aggressive_shrink_switch. cma_aggressive_switch is the swith for all CMA_AGGRESSIVE function. It can be controlled by sysctl vm.cma-aggressive-switch. cma_aggressive_free_min can be controlled by sysctl "vm.cma-aggressive-free-min". If the number of CMA free pages is small than this sysctl value, CMA_AGGRESSIVE will not work in page alloc code. cma_aggressive_shrink_switch can be controlled by sysctl "vm.cma-aggressive-shrink-switch". If sysctl "vm.cma-aggressive-shrink-switch" is true and free normal memory's size is smaller than the size that it want to allocate, do memory shrink with function git commit -a --amend before driver allocate pages from CMA. When Linux kernel try to reserve custom contiguous area, increase the value of cma_alloc_counter. CMA_AGGRESSIVE will not work in page alloc code. After reserve custom contiguous area function return, decreases the value of cma_alloc_counter. Signed-off-by: Hui Zhu --- include/linux/cma.h | 7 +++++++ kernel/sysctl.c | 27 +++++++++++++++++++++++++++ mm/cma.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) diff --git a/include/linux/cma.h b/include/linux/cma.h index 0430ed0..df96abf 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -15,6 +15,13 @@ struct cma; +#ifdef CONFIG_CMA_AGGRESSIVE +extern atomic_t cma_alloc_counter; +extern int cma_aggressive_switch; +extern unsigned long cma_aggressive_free_min; +extern int cma_aggressive_shrink_switch; +#endif + extern phys_addr_t cma_get_base(struct cma *cma); extern unsigned long cma_get_size(struct cma *cma); diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 4aada6d..646929e2 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -92,6 +92,10 @@ #include #endif +#ifdef CONFIG_CMA_AGGRESSIVE +#include +#endif + #if defined(CONFIG_SYSCTL) @@ -1485,6 +1489,29 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_CMA_AGGRESSIVE + { + .procname = "cma-aggressive-switch", + .data = &cma_aggressive_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, + { + .procname = "cma-aggressive-free-min", + .data = &cma_aggressive_free_min, + .maxlen = sizeof(unsigned long), + .mode = 0600, + .proc_handler = proc_doulongvec_minmax, + }, + { + .procname = "cma-aggressive-shrink-switch", + .data = &cma_aggressive_shrink_switch, + .maxlen = sizeof(int), + .mode = 0600, + .proc_handler = proc_dointvec, + }, +#endif { } }; diff --git a/mm/cma.c b/mm/cma.c index 963bc4a..1cf341c 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -33,6 +33,7 @@ #include #include #include +#include struct cma { unsigned long base_pfn; @@ -127,6 +128,27 @@ err: return -EINVAL; } +#ifdef CONFIG_CMA_AGGRESSIVE +/* The counter for the dma_alloc_from_contiguous and + dma_release_from_contiguous. */ +atomic_t cma_alloc_counter = ATOMIC_INIT(0); + +/* Swich of CMA_AGGRESSIVE. */ +int cma_aggressive_switch __read_mostly; + +/* If the number of CMA free pages is small than this value, CMA_AGGRESSIVE will + not work. */ +#ifdef CONFIG_CMA_AGGRESSIVE_FREE_MIN +unsigned long cma_aggressive_free_min __read_mostly = + CONFIG_CMA_AGGRESSIVE_FREE_MIN; +#else +unsigned long cma_aggressive_free_min __read_mostly = 500; +#endif + +/* Swich of CMA_AGGRESSIVE shink. */ +int cma_aggressive_shrink_switch __read_mostly; +#endif + static int __init cma_init_reserved_areas(void) { int i; @@ -138,6 +160,22 @@ static int __init cma_init_reserved_areas(void) return ret; } +#ifdef CONFIG_CMA_AGGRESSIVE + cma_aggressive_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_PHY_MAX + if (memblock_phys_mem_size() <= CONFIG_CMA_AGGRESSIVE_PHY_MAX) +#else + if (memblock_phys_mem_size() <= 0x40000000) +#endif + cma_aggressive_switch = 1; + + cma_aggressive_shrink_switch = 0; +#ifdef CONFIG_CMA_AGGRESSIVE_SHRINK + if (cma_aggressive_switch) + cma_aggressive_shrink_switch = 1; +#endif +#endif + return 0; } core_initcall(cma_init_reserved_areas); @@ -312,6 +350,11 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) unsigned long bitmap_maxno, bitmap_no, bitmap_count; struct page *page = NULL; int ret; +#ifdef CONFIG_CMA_AGGRESSIVE + int free = global_page_state(NR_FREE_PAGES) + - global_page_state(NR_FREE_CMA_PAGES) + - totalreserve_pages; +#endif if (!cma || !cma->count) return NULL; @@ -326,6 +369,13 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) bitmap_maxno = cma_bitmap_maxno(cma); bitmap_count = cma_bitmap_pages_to_bits(cma, count); +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_inc(&cma_alloc_counter); + if (cma_aggressive_switch && cma_aggressive_shrink_switch + && free < count) + shrink_all_memory_for_cma(count - free); +#endif + for (;;) { mutex_lock(&cma->lock); bitmap_no = bitmap_find_next_zero_area(cma->bitmap, @@ -361,6 +411,10 @@ struct page *cma_alloc(struct cma *cma, int count, unsigned int align) start = bitmap_no + mask + 1; } +#ifdef CONFIG_CMA_AGGRESSIVE + atomic_dec(&cma_alloc_counter); +#endif + pr_debug("%s(): returned %p\n", __func__, page); return page; } -- 1.9.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753932AbaJVFod (ORCPT ); Wed, 22 Oct 2014 01:44:33 -0400 Received: from [42.62.48.242] ([42.62.48.242]:37942 "EHLO manager.mioffice.cn" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750831AbaJVFob (ORCPT ); Wed, 22 Oct 2014 01:44:31 -0400 From: =?gb2312?B?1uy71A==?= To: Pavel Machek CC: "rjw@rjwysocki.net" , "len.brown@intel.com" , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "riel@redhat.com" , "mgorman@suse.de" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "hughd@google.com" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "akinobu.mita@gmail.com" , "lauraa@codeaurora.org" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Thread-Topic: [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Thread-Index: AQHP6PJVlMR9bONqakO6B9lMcs478w== Date: Wed, 22 Oct 2014 05:44:24 +0000 Message-ID: <2c27ad87839b42ca85c03c9541550d30@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-2-git-send-email-zhuhui@xiaomi.com> <201410220126.s9M1Qita026502@spam.xiaomi.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.37.216.50] Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id s9M5ic53004559 On 10/22/14 09:27, Pavel Machek wrote: > Hi! > >> Add CMA_AGGRESSIVE config that depend on CMA to Linux kernel config. >> Add CMA_AGGRESSIVE_PHY_MAX, CMA_AGGRESSIVE_FREE_MIN and CMA_AGGRESSIVE_SHRINK >> that depend on CMA_AGGRESSIVE. >> >> If physical memory size (not include CMA memory) in byte less than or equal to >> CMA_AGGRESSIVE_PHY_MAX, CMA aggressive switch (sysctl vm.cma-aggressive-switch) >> will be opened. > > Ok... > > Do I understand it correctly that there is some problem with > hibernation not working on machines not working on machines with big > CMA areas...? No, these patches want to handle this issue that most of CMA memory is not allocated before lowmemorykiller or oom_killer begin to kill tasks. > > But adding 4 config options end-user has no chance to set right can > not be the best solution, can it? > >> +config CMA_AGGRESSIVE_PHY_MAX >> + hex "Physical memory size in Bytes that auto turn on the CMA aggressive switch" >> + depends on CMA_AGGRESSIVE >> + default 0x40000000 >> + help >> + If physical memory size (not include CMA memory) in byte less than or >> + equal to this value, CMA aggressive switch will be opened. >> + After the Linux boot, sysctl "vm.cma-aggressive-switch" can control >> + the CMA AGGRESSIVE switch. > > For example... how am I expected to figure right value to place here? I agree with that. I will update this config to auto set in next version. Thanks, Hui > > Pavel > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933460AbaJVMC2 (ORCPT ); Wed, 22 Oct 2014 08:02:28 -0400 Received: from mailout32.mail01.mtsvc.net ([216.70.64.70]:56752 "EHLO n23.mail01.mtsvc.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933056AbaJVMC0 (ORCPT ); Wed, 22 Oct 2014 08:02:26 -0400 X-Greylist: delayed 60989 seconds by postgrey-1.27 at vger.kernel.org; Wed, 22 Oct 2014 08:02:26 EDT Message-ID: <54479CB2.5040408@hurleysoftware.com> Date: Wed, 22 Oct 2014 08:01:54 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Laura Abbott , Hui Zhu , m.szyprowski@samsung.com, akpm@linux-foundation.org, riel@redhat.com, mgorman@suse.de, hughd@google.com, akinobu.mita@gmail.com CC: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> In-Reply-To: <543F8812.2020002@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated-User: 990527 peter@hurleysoftware.com X-MT-ID: 8FA290C2A27252AACF65DBC4A42F3CE3735FB2A4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/2014 04:55 AM, Laura Abbott wrote: > On 10/15/2014 8:35 PM, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. >> > > 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. What impact does this series have on x86 platforms now that CMA is the backup allocator for all iommu dma allocations? Regards, Peter Hurley From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933618AbaJWAlQ (ORCPT ); Wed, 22 Oct 2014 20:41:16 -0400 Received: from [42.62.48.242] ([42.62.48.242]:29681 "EHLO outbound.mxmail.xiaomi.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754359AbaJWAlO (ORCPT ); Wed, 22 Oct 2014 20:41:14 -0400 From: =?gb2312?B?1uy71A==?= To: Peter Hurley , Laura Abbott , "m.szyprowski@samsung.com" , "akpm@linux-foundation.org" , "riel@redhat.com" , "mgorman@suse.de" , "hughd@google.com" , "akinobu.mita@gmail.com" CC: "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "mina86@mina86.com" , "aneesh.kumar@linux.vnet.ibm.com" , "iamjoonsoo.kim@lge.com" , "hannes@cmpxchg.org" , "minchan@kernel.org" , "nasa4836@gmail.com" , "ddstreet@ieee.org" , "mingo@kernel.org" , "rientjes@google.com" , "peterz@infradead.org" , "keescook@chromium.org" , "atomlin@redhat.com" , "raistlin@linux.it" , "axboe@fb.com" , "paulmck@linux.vnet.ibm.com" , "kirill.shutemov@linux.intel.com" , "n-horiguchi@ah.jp.nec.com" , "k.khlebnikov@samsung.com" , "msalter@redhat.com" , "deller@gmx.de" , "tangchen@cn.fujitsu.com" , "ben@decadent.org.uk" , "vbabka@suse.cz" , "sasha.levin@oracle.com" , "vdavydov@parallels.com" , "suleiman@google.com" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Thread-Topic: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Thread-Index: AQHP6PJVOSZsZeZKBkSR9KhOfKwh0g== Date: Thu, 23 Oct 2014 00:40:57 +0000 Message-ID: <04a07ed889c840f1919e220f906af3af@cnbox4.mioffice.cn> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <54479CB2.5040408@hurleysoftware.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.37.216.50] Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id s9N0fLid012047 On 10/22/14 20:02, Peter Hurley wrote: > On 10/16/2014 04:55 AM, Laura Abbott wrote: >> On 10/15/2014 8:35 PM, Hui Zhu wrote: >>> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >>> MIGRATE_MOVABLE. >>> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >>> order that Linux kernel want. >>> >>> If a system that has a lot of user space program is running, for >>> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >>> allocated. Before function __rmqueue_fallback get memory from >>> MIGRATE_CMA, the oom_killer will kill a task to release memory when >>> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >>> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >>> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >>> kernel kill some tasks to release memory. >>> >>> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >>> be more aggressive about allocation. >>> If function CMA_AGGRESSIVE is available, when Linux kernel call function >>> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >>> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >>> doesn't have enough pages for allocation, go back to allocate memory from >>> MIGRATE_MOVABLE. >>> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >>> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. >>> >> >> 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. > > What impact does this series have on x86 platforms now that CMA is the > backup allocator for all iommu dma allocations? They will not affect driver CMA memory allocation. Thanks, Hui > > Regards, > Peter Hurley > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755655AbaJXF1r (ORCPT ); Fri, 24 Oct 2014 01:27:47 -0400 Received: from lgeamrelo02.lge.com ([156.147.1.126]:34726 "EHLO lgeamrelo02.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752601AbaJXF1q (ORCPT ); Fri, 24 Oct 2014 01:27:46 -0400 X-Original-SENDERIP: 10.177.222.213 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Fri, 24 Oct 2014 14:28:50 +0900 From: Joonsoo Kim To: Hui Zhu Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Message-ID: <20141024052849.GF15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote: > If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and > conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) > allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. > > Signed-off-by: Hui Zhu > --- > mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- > 1 file changed, 31 insertions(+), 11 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 736d8e1..87bc326 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -65,6 +65,10 @@ > #include > #include "internal.h" > > +#ifdef CONFIG_CMA_AGGRESSIVE > +#include > +#endif > + > /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ > static DEFINE_MUTEX(pcp_batch_high_lock); > #define MIN_PERCPU_PAGELIST_FRACTION (8) > @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, > { > struct page *page; > > -retry_reserve: > +#ifdef CONFIG_CMA_AGGRESSIVE > + if (cma_aggressive_switch > + && migratetype == MIGRATE_MOVABLE > + && atomic_read(&cma_alloc_counter) == 0 > + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min > + + (1 << order)) > + migratetype = MIGRATE_CMA; > +#endif > +retry: I don't get it why cma_alloc_counter should be tested. When cma alloc is progress, pageblock is isolated so that pages on that pageblock cannot be allocated. Why should we prevent aggressive allocation in this case? Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751658AbaKCH3X (ORCPT ); Mon, 3 Nov 2014 02:29:23 -0500 Received: from mail-ob0-f178.google.com ([209.85.214.178]:59890 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751613AbaKCH3T (ORCPT ); Mon, 3 Nov 2014 02:29:19 -0500 MIME-Version: 1.0 In-Reply-To: <20141024052553.GE15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> From: Hui Zhu Date: Mon, 3 Nov 2014 15:28:38 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of >> MIGRATE_MOVABLE. >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in >> order that Linux kernel want. >> >> If a system that has a lot of user space program is running, for >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and >> allocated. Before function __rmqueue_fallback get memory from >> MIGRATE_CMA, the oom_killer will kill a task to release memory when >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux >> kernel kill some tasks to release memory. >> >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory >> be more aggressive about allocation. >> If function CMA_AGGRESSIVE is available, when Linux kernel call function >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA >> doesn't have enough pages for allocation, go back to allocate memory from >> MIGRATE_MOVABLE. >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > Hello, > > I did some work similar to this. > Please reference following links. > > https://lkml.org/lkml/2014/5/28/64 > https://lkml.org/lkml/2014/5/28/57 > I tested #1 approach and found the problem. Although free memory on > meminfo can move around low watermark, there is large fluctuation on free > memory, because too many pages are reclaimed when kswapd is invoked. > Reason for this behaviour is that successive allocated CMA pages are > on the LRU list in that order and kswapd reclaim them in same order. > These memory doesn't help watermark checking from kwapd, so too many > pages are reclaimed, I guess. This issue can be handle with some change around shrink code. I am trying to integrate a patch for them. But I am not sure we met the same issue. Do you mind give me more info about this part? > > And, aggressive allocation should be postponed until freepage counting > bug is fixed, because aggressive allocation enlarge the possiblity > of problem occurence. I tried to fix that bug, too. See following link. > > https://lkml.org/lkml/2014/10/23/90 I am following these patches. They are great! Thanks for your work. Best, Hui > > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751379AbaKCIEO (ORCPT ); Mon, 3 Nov 2014 03:04:14 -0500 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:48150 "EHLO lgemrelse6q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbaKCIEM (ORCPT ); Mon, 3 Nov 2014 03:04:12 -0500 X-Original-SENDERIP: 10.177.222.213 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Mon, 3 Nov 2014 17:05:46 +0900 From: Joonsoo Kim To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141103080546.GB7052@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > >> MIGRATE_MOVABLE. > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > >> order that Linux kernel want. > >> > >> If a system that has a lot of user space program is running, for > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > >> allocated. Before function __rmqueue_fallback get memory from > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > >> kernel kill some tasks to release memory. > >> > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > >> be more aggressive about allocation. > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > >> doesn't have enough pages for allocation, go back to allocate memory from > >> MIGRATE_MOVABLE. > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > Hello, > > > > I did some work similar to this. > > Please reference following links. > > > > https://lkml.org/lkml/2014/5/28/64 > > https://lkml.org/lkml/2014/5/28/57 > > > I tested #1 approach and found the problem. Although free memory on > > meminfo can move around low watermark, there is large fluctuation on free > > memory, because too many pages are reclaimed when kswapd is invoked. > > Reason for this behaviour is that successive allocated CMA pages are > > on the LRU list in that order and kswapd reclaim them in same order. > > These memory doesn't help watermark checking from kwapd, so too many > > pages are reclaimed, I guess. > > This issue can be handle with some change around shrink code. I am > trying to integrate a patch for them. > But I am not sure we met the same issue. Do you mind give me more > info about this part? I forgot the issue because there is so big time-gap. I need sometime to bring issue back to my brain. I will answer it soon after some thinking. > > > > > And, aggressive allocation should be postponed until freepage counting > > bug is fixed, because aggressive allocation enlarge the possiblity > > of problem occurence. I tried to fix that bug, too. See following link. > > > > https://lkml.org/lkml/2014/10/23/90 > > I am following these patches. They are great! Thanks for your work. Thanks. :) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751987AbaKCIrL (ORCPT ); Mon, 3 Nov 2014 03:47:11 -0500 Received: from mail-oi0-f43.google.com ([209.85.218.43]:45919 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbaKCIrE (ORCPT ); Mon, 3 Nov 2014 03:47:04 -0500 MIME-Version: 1.0 In-Reply-To: <5450FD15.4000708@suse.cz> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> From: Hui Zhu Date: Mon, 3 Nov 2014 16:46:23 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation To: Vlastimil Babka , iamjoonsoo.kim@lge.com Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 29, 2014 at 10:43 PM, 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 > - it's more complex, but I guess we have most of the necessary > infrastructure in compaction already :) I think this idea make CMA allocation part become complex but make balance and shrink code become easy because it make CMA become real memory. I just worry about the speed of migrate memory with this idea. :) Thanks, Hui > > Thoughts? > Vlastimil > >> Thanks, >> Laura >> > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752964AbaKDC3d (ORCPT ); Mon, 3 Nov 2014 21:29:33 -0500 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:38298 "EHLO lgemrelse6q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751558AbaKDC33 (ORCPT ); Mon, 3 Nov 2014 21:29:29 -0500 X-Original-SENDERIP: 10.177.222.213 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Tue, 4 Nov 2014 11:31:12 +0900 From: Joonsoo Kim To: Hui Zhu Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141104023112.GA17804@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <20141024052553.GE15243@js1304-P5Q-DELUXE> <20141103080546.GB7052@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103080546.GB7052@js1304-P5Q-DELUXE> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 03, 2014 at 05:05:46PM +0900, Joonsoo Kim wrote: > On Mon, Nov 03, 2014 at 03:28:38PM +0800, Hui Zhu wrote: > > On Fri, Oct 24, 2014 at 1:25 PM, Joonsoo Kim wrote: > > > On Thu, Oct 16, 2014 at 11:35:47AM +0800, Hui Zhu wrote: > > >> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of > > >> MIGRATE_MOVABLE. > > >> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in > > >> order that Linux kernel want. > > >> > > >> If a system that has a lot of user space program is running, for > > >> instance, an Android board, most of memory is in MIGRATE_MOVABLE and > > >> allocated. Before function __rmqueue_fallback get memory from > > >> MIGRATE_CMA, the oom_killer will kill a task to release memory when > > >> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of > > >> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE. > > >> This status is odd. The MIGRATE_CMA has a lot free memory but Linux > > >> kernel kill some tasks to release memory. > > >> > > >> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory > > >> be more aggressive about allocation. > > >> If function CMA_AGGRESSIVE is available, when Linux kernel call function > > >> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow, > > >> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. If MIGRATE_CMA > > >> doesn't have enough pages for allocation, go back to allocate memory from > > >> MIGRATE_MOVABLE. > > >> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and > > >> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA. > > > > > > Hello, > > > > > > I did some work similar to this. > > > Please reference following links. > > > > > > https://lkml.org/lkml/2014/5/28/64 > > > https://lkml.org/lkml/2014/5/28/57 > > > > > I tested #1 approach and found the problem. Although free memory on > > > meminfo can move around low watermark, there is large fluctuation on free > > > memory, because too many pages are reclaimed when kswapd is invoked. > > > Reason for this behaviour is that successive allocated CMA pages are > > > on the LRU list in that order and kswapd reclaim them in same order. > > > These memory doesn't help watermark checking from kwapd, so too many > > > pages are reclaimed, I guess. > > > > This issue can be handle with some change around shrink code. I am > > trying to integrate a patch for them. > > But I am not sure we met the same issue. Do you mind give me more > > info about this part? > > I forgot the issue because there is so big time-gap. I need sometime > to bring issue back to my brain. I will answer it soon after some thinking. Hello, Yes, the issue I mentioned before can be handled by modifying shrink code. I didn't dive into the problem so I also didn't know the detail. What I know is that there is large fluctuation on memory statistics and my guess is that it is caused by order of reclaimable pages. If we use #1 approach, the bulk of cma pages used for page cache or something are linked together and will be reclaimed all at once, because reclaiming cma pages are not counted and watermark check still fails until normal pages are reclaimed. I think that round-robin approach is better. Reasons are on the following: 1) Want to spread CMA freepages to whole users, not specific one user. We can modify shirnk code not to reclaim pages on CMA, because it doesn't help watermark checking in some cases. In this case, if we don't use round-robin, one specific user whose mapping with CMA pages can get all the benefit. Others would take all the overhead. I think that spreading will make all users fair. 2) Using CMA freepages first needlessly imposes overhead to CMA user. If the system has enough normal freepages, it is better not to use it as much as possible. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752202AbaKDHwV (ORCPT ); Tue, 4 Nov 2014 02:52:21 -0500 Received: from lgeamrelo01.lge.com ([156.147.1.125]:42455 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989AbaKDHwT (ORCPT ); Tue, 4 Nov 2014 02:52:19 -0500 X-Original-SENDERIP: 10.177.220.156 X-Original-MAILFROM: minchan@kernel.org Date: Tue, 4 Nov 2014 16:53:30 +0900 From: Minchan Kim To: Vlastimil Babka Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141104075330.GB23102@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5450FD15.4000708@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752694AbaKDJAL (ORCPT ); Tue, 4 Nov 2014 04:00:11 -0500 Received: from mail-oi0-f54.google.com ([209.85.218.54]:35795 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751247AbaKDJAF (ORCPT ); Tue, 4 Nov 2014 04:00:05 -0500 MIME-Version: 1.0 In-Reply-To: <20141104075330.GB23102@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> From: Hui Zhu Date: Tue, 4 Nov 2014 16:59:24 +0800 Message-ID: Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation To: Minchan Kim Cc: Vlastimil Babka , Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 4, 2014 at 3:53 PM, Minchan Kim wrote: > 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. Thanks. > > 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. Even if kernel use it to allocate the CMA memory, CMA alloc latency will happen if most of memory is allocated and driver try to get CMA memory. https://lkml.org/lkml/2014/10/17/129 https://lkml.org/lkml/2014/10/17/130 These patches let cma_alloc do a shrink with function shrink_all_memory_for_cma if need. It handle a lot of latency issue in my part. And I think it can be more configurable for example some device use it and others not. Thanks, Hui > >> >> Thoughts? >> Vlastimil >> >> >Thanks, >> >Laura >> > >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email@kvack.org > > -- > Kind regards, > Minchan Kim > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752579AbaKDJaL (ORCPT ); Tue, 4 Nov 2014 04:30:11 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40890 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751001AbaKDJaH (ORCPT ); Tue, 4 Nov 2014 04:30:07 -0500 Message-ID: <54589C97.4060309@suse.cz> Date: Tue, 04 Nov 2014 10:29:59 +0100 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Minchan Kim CC: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> In-Reply-To: <20141104075330.GB23102@bbox> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/04/2014 08:53 AM, Minchan Kim wrote: > Hello, > > On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: >> On 10/16/2014 10:55 AM, Laura Abbott wrote: >> >> 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. Well, if it relaims CMA pages, then it has to be followed by the migration. Is that better or worse than breaking LRU assumptions by reclaiming based on where the page is located? I thought this was basically what lumpy reclaim did, and it was removed. > 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. Yeah that would be great. > 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 I'm not sure I understand enough from this. You want to introduce a movable zone instead of CMA pageblocks? But how to size it, resize it, would it be possible? > 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. Why would it overlap in the first place? Just because it wouldn't be sized on pageblock boundary? Or to make (re)sizing simpler? Yeah we could probably handle that, but it's not completely for free (you iterate over blocks/pages uselessly). > 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. Yeah maybe it could be simpler in the end. Although a new zone type could be a disturbing change, with some overhead to per-cpu structures etc. The allocations in that zone would be somewhat at disadvantage wrt LRU, as CMA allocation would mostly reclaim them instead of migrating away (assuming there wouldn't be so much spare space for migration as when CMA pageblocks are part of a much larger zone). But I guess the same could be said about the DMA zone... >> >> Thoughts? >> Vlastimil >> >>> Thanks, >>> Laura >>> >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email@kvack.org > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751320AbaKGHFe (ORCPT ); Fri, 7 Nov 2014 02:05:34 -0500 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:44303 "EHLO lgemrelse6q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbaKGHFd (ORCPT ); Fri, 7 Nov 2014 02:05:33 -0500 X-Original-SENDERIP: 10.177.220.156 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 7 Nov 2014 16:06:55 +0900 From: Minchan Kim To: Vlastimil Babka Cc: Laura Abbott , Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, akpm@linux-foundation.org, mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com, mgorman@suse.de, nasa4836@gmail.com, ddstreet@ieee.org, hughd@google.com, mingo@kernel.org, rientjes@google.com, peterz@infradead.org, keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Message-ID: <20141107070655.GA3486@bbox> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <543F8812.2020002@codeaurora.org> <5450FD15.4000708@suse.cz> <20141104075330.GB23102@bbox> <54589C97.4060309@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54589C97.4060309@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tue, Nov 04, 2014 at 10:29:59AM +0100, Vlastimil Babka wrote: > On 11/04/2014 08:53 AM, Minchan Kim wrote: > >Hello, > > > >On Wed, Oct 29, 2014 at 03:43:33PM +0100, Vlastimil Babka wrote: > >>On 10/16/2014 10:55 AM, Laura Abbott wrote: > >> > >>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. > > Well, if it relaims CMA pages, then it has to be followed by the > migration. Is that better or worse than breaking LRU assumptions by > reclaiming based on where the page is located? I thought this was > basically what lumpy reclaim did, and it was removed. It would work and it might cost for using for CMA because CMA already can migrate/discard lots of pages, which will hurt LRU assumption. However, I don't think it's optimal. > > >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. > > Yeah that would be great. > > >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 > > I'm not sure I understand enough from this. You want to introduce a > movable zone instead of CMA pageblocks? But how to size it, resize > it, would it be possible? Why do we need to care of resizing? All of CMA pages are reserved by using memblock during boot. If we can set the zone size after that, maybe we don't need to resize the zone. > > >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. > > Why would it overlap in the first place? Just because it wouldn't be > sized on pageblock boundary? Or to make (re)sizing simpler? Yeah we > could probably handle that, but it's not completely for free (you > iterate over blocks/pages uselessly). Reserved pages for CMA are spread over the system memory. So zones could overlap each other so we need check that overlapping like pageblock_pfn_to_page while we need to walk pfn in order. It's not free but it would add the overhead pfn-order walking like compaction, which is not hot path. > > >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. > > Yeah maybe it could be simpler in the end. Although a new zone type > could be a disturbing change, with some overhead to per-cpu > structures etc. The allocations in that zone would be somewhat at > disadvantage wrt LRU, as CMA allocation would mostly reclaim them > instead of migrating away (assuming there wouldn't be so much spare > space for migration as when CMA pageblocks are part of a much larger > zone). But I guess the same could be said about the DMA zone... What do you mean "CMA allocation"? If you meant movable pages allocation like userspace page, it would be round-robin by fair zone policy. If you meant device request for contiguous memory allocation so we should reclaim CMA pages due to lack of spare memory, we don't have no choice. IOW, it's trade-off for using CMA. > > >> > >>Thoughts? > >>Vlastimil > >> > >>>Thanks, > >>>Laura > >>> > >> > >>-- > >>To unsubscribe, send a message with 'unsubscribe linux-mm' in > >>the body to majordomo@kvack.org. For more info on Linux MM, > >>see: http://www.linux-mm.org/ . > >>Don't email: email@kvack.org > > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751107AbaK1Dpr (ORCPT ); Thu, 27 Nov 2014 22:45:47 -0500 Received: from mail-oi0-f46.google.com ([209.85.218.46]:63884 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbaK1Dpp (ORCPT ); Thu, 27 Nov 2014 22:45:45 -0500 MIME-Version: 1.0 In-Reply-To: <20141024052849.GF15243@js1304-P5Q-DELUXE> References: <1413430551-22392-1-git-send-email-zhuhui@xiaomi.com> <1413430551-22392-5-git-send-email-zhuhui@xiaomi.com> <20141024052849.GF15243@js1304-P5Q-DELUXE> From: Hui Zhu Date: Fri, 28 Nov 2014 11:45:04 +0800 Message-ID: Subject: Re: [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function To: Joonsoo Kim Cc: Hui Zhu , rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz, m.szyprowski@samsung.com, Andrew Morton , mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com, hannes@cmpxchg.org, Rik van Riel , mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com, ddstreet@ieee.org, Hugh Dickins , mingo@kernel.org, rientjes@google.com, Peter Zijlstra , keescook@chromium.org, atomlin@redhat.com, raistlin@linux.it, axboe@fb.com, Paul McKenney , kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com, msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com, ben@decadent.org.uk, akinobu.mita@gmail.com, lauraa@codeaurora.org, vbabka@suse.cz, sasha.levin@oracle.com, vdavydov@parallels.com, suleiman@google.com, "linux-kernel@vger.kernel.org" , linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 24, 2014 at 1:28 PM, Joonsoo Kim wrote: > On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote: >> If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and >> conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter) >> allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first. >> >> Signed-off-by: Hui Zhu >> --- >> mm/page_alloc.c | 42 +++++++++++++++++++++++++++++++----------- >> 1 file changed, 31 insertions(+), 11 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 736d8e1..87bc326 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -65,6 +65,10 @@ >> #include >> #include "internal.h" >> >> +#ifdef CONFIG_CMA_AGGRESSIVE >> +#include >> +#endif >> + >> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ >> static DEFINE_MUTEX(pcp_batch_high_lock); >> #define MIN_PERCPU_PAGELIST_FRACTION (8) >> @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, >> { >> struct page *page; >> >> -retry_reserve: >> +#ifdef CONFIG_CMA_AGGRESSIVE >> + if (cma_aggressive_switch >> + && migratetype == MIGRATE_MOVABLE >> + && atomic_read(&cma_alloc_counter) == 0 >> + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min >> + + (1 << order)) >> + migratetype = MIGRATE_CMA; >> +#endif >> +retry: > > I don't get it why cma_alloc_counter should be tested. > When cma alloc is progress, pageblock is isolated so that pages on that > pageblock cannot be allocated. Why should we prevent aggressive > allocation in this case? > Hi Joonsoo, Even if the pageblock is isolated in the begin of function alloc_contig_range, it will unisolate if alloc_contig_range get some error for example "PFNs busy". And the cma_alloc will keep call alloc_contig_range with another address if need. So it will decrease the contradiction between CMA allocation in cma_alloc and __rmqueue with cma_alloc_counter. Thanks, Hui > Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org