From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 5B5A96B0069 for ; Wed, 28 Dec 2016 10:30:41 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id xr1so90398196wjb.7 for ; Wed, 28 Dec 2016 07:30:41 -0800 (PST) Received: from mail-wj0-f193.google.com (mail-wj0-f193.google.com. [209.85.210.193]) by mx.google.com with ESMTPS id q185si50693441wmb.94.2016.12.28.07.30.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:39 -0800 (PST) Received: by mail-wj0-f193.google.com with SMTP id j10so54868422wjb.3 for ; Wed, 28 Dec 2016 07:30:39 -0800 (PST) From: Michal Hocko Subject: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Date: Wed, 28 Dec 2016 16:30:25 +0100 Message-Id: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Hi, while debugging [1] I've realized that there is some room for improvements in the tracepoints set we offer currently. I had hard times to make any conclusion from the existing ones. The resulting problem turned out to be active list aging [2] and we are missing at least two tracepoints to debug such a problem. Some existing tracepoints could export more information to see _why_ the reclaim progress cannot be made not only _how much_ we could reclaim. The later could be seen quite reasonably from the vmstat counters already. It can be argued that we are showing too many implementation details in those tracepoints but I consider them way too lowlevel already to be usable by any kernel independent userspace. I would be _really_ surprised if anything but debugging tools have used them. Any feedback is highly appreciated. [1] http://lkml.kernel.org/r/20161215225702.GA27944@boerne.fritz.box [2] http://lkml.kernel.org/r/20161223105157.GB23109@dhcp22.suse.cz -- 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-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id A5DA56B0069 for ; Wed, 28 Dec 2016 10:30:41 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id i131so59421896wmf.3 for ; Wed, 28 Dec 2016 07:30:41 -0800 (PST) Received: from mail-wj0-f195.google.com (mail-wj0-f195.google.com. [209.85.210.195]) by mx.google.com with ESMTPS id r4si21172098wme.125.2016.12.28.07.30.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:40 -0800 (PST) Received: by mail-wj0-f195.google.com with SMTP id kp2so54789230wjc.0 for ; Wed, 28 Dec 2016 07:30:40 -0800 (PST) From: Michal Hocko Subject: [PATCH 1/7] mm, vmscan: remove unused mm_vmscan_memcg_isolate Date: Wed, 28 Dec 2016 16:30:26 +0100 Message-Id: <20161228153032.10821-2-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko the trace point is not used since 925b7673cce3 ("mm: make per-memcg LRU lists exclusive") so it can be removed. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index c88fd0934e7e..39bad8921ca1 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -269,8 +269,7 @@ TRACE_EVENT(mm_shrink_slab_end, __entry->retval) ); -DECLARE_EVENT_CLASS(mm_vmscan_lru_isolate_template, - +TRACE_EVENT(mm_vmscan_lru_isolate, TP_PROTO(int classzone_idx, int order, unsigned long nr_requested, @@ -311,34 +310,6 @@ DECLARE_EVENT_CLASS(mm_vmscan_lru_isolate_template, __entry->file) ); -DEFINE_EVENT(mm_vmscan_lru_isolate_template, mm_vmscan_lru_isolate, - - TP_PROTO(int classzone_idx, - int order, - unsigned long nr_requested, - unsigned long nr_scanned, - unsigned long nr_taken, - isolate_mode_t isolate_mode, - int file), - - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file) - -); - -DEFINE_EVENT(mm_vmscan_lru_isolate_template, mm_vmscan_memcg_isolate, - - TP_PROTO(int classzone_idx, - int order, - unsigned long nr_requested, - unsigned long nr_scanned, - unsigned long nr_taken, - isolate_mode_t isolate_mode, - int file), - - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file) - -); - TRACE_EVENT(mm_vmscan_writepage, TP_PROTO(struct page *page), -- 2.10.2 -- 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-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 22F9C6B025E for ; Wed, 28 Dec 2016 10:30:43 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id u144so59456882wmu.1 for ; Wed, 28 Dec 2016 07:30:43 -0800 (PST) Received: from mail-wj0-f196.google.com (mail-wj0-f196.google.com. [209.85.210.196]) by mx.google.com with ESMTPS id h14si50716147wmg.22.2016.12.28.07.30.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:41 -0800 (PST) Received: by mail-wj0-f196.google.com with SMTP id hb5so21632161wjc.2 for ; Wed, 28 Dec 2016 07:30:41 -0800 (PST) From: Michal Hocko Subject: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Wed, 28 Dec 2016 16:30:27 +0100 Message-Id: <20161228153032.10821-3-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko Our reclaim process has several tracepoints to tell us more about how things are progressing. We are, however, missing a tracepoint to track active list aging. Introduce mm_vmscan_lru_shrink_active which reports the number of scanned, rotated, deactivated and freed pages from the particular node's active list. Signed-off-by: Michal Hocko --- include/linux/gfp.h | 2 +- include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 6 +++++- mm/vmscan.c | 22 +++++++++++++++++----- 4 files changed, 61 insertions(+), 7 deletions(-) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 4175dca4ac39..61aa9b49e86d 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); extern void __free_pages(struct page *page, unsigned int order); extern void free_pages(unsigned long addr, unsigned int order); extern void free_hot_cold_page(struct page *page, bool cold); -extern void free_hot_cold_page_list(struct list_head *list, bool cold); +extern int free_hot_cold_page_list(struct list_head *list, bool cold); struct page_frag_cache; extern void __page_frag_drain(struct page *page, unsigned int order, diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 39bad8921ca1..d34cc0ced2be 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_vmscan_lru_shrink_active, + + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, + unsigned long nr_unevictable, unsigned long nr_deactivated, + unsigned long nr_rotated, int priority, int file), + + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), + + TP_STRUCT__entry( + __field(int, nid) + __field(unsigned long, nr_scanned) + __field(unsigned long, nr_freed) + __field(unsigned long, nr_unevictable) + __field(unsigned long, nr_deactivated) + __field(unsigned long, nr_rotated) + __field(int, priority) + __field(int, reclaim_flags) + ), + + TP_fast_assign( + __entry->nid = nid; + __entry->nr_scanned = nr_scanned; + __entry->nr_freed = nr_freed; + __entry->nr_unevictable = nr_unevictable; + __entry->nr_deactivated = nr_deactivated; + __entry->nr_rotated = nr_rotated; + __entry->priority = priority; + __entry->reclaim_flags = trace_shrink_flags(file); + ), + + TP_printk("nid=%d nr_scanned=%ld nr_freed=%ld nr_unevictable=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", + __entry->nid, + __entry->nr_scanned, __entry->nr_freed, __entry->nr_unevictable, + __entry->nr_deactivated, __entry->nr_rotated, + __entry->priority, + show_reclaim_flags(__entry->reclaim_flags)) +); + #endif /* _TRACE_VMSCAN_H */ /* This part must be outside protection */ diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1c24112308d6..77d204660857 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2487,14 +2487,18 @@ void free_hot_cold_page(struct page *page, bool cold) /* * Free a list of 0-order pages */ -void free_hot_cold_page_list(struct list_head *list, bool cold) +int free_hot_cold_page_list(struct list_head *list, bool cold) { struct page *page, *next; + int ret = 0; list_for_each_entry_safe(page, next, list, lru) { trace_mm_page_free_batched(page, cold); free_hot_cold_page(page, cold); + ret++; } + + return ret; } /* diff --git a/mm/vmscan.c b/mm/vmscan.c index c4abf08861d2..2302a1a58c6e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * * The downside is that we have to touch page->_refcount against each page. * But we had to alter page->flags anyway. + * + * Returns the number of pages moved to the given lru. */ -static void move_active_pages_to_lru(struct lruvec *lruvec, +static int move_active_pages_to_lru(struct lruvec *lruvec, struct list_head *list, struct list_head *pages_to_free, enum lru_list lru) @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, unsigned long pgmoved = 0; struct page *page; int nr_pages; + int nr_moved = 0; while (!list_empty(list)) { page = lru_to_page(list); @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, spin_lock_irq(&pgdat->lru_lock); } else list_add(&page->lru, pages_to_free); + } else { + nr_moved++; } } if (!is_active_lru(lru)) __count_vm_events(PGDEACTIVATE, pgmoved); + + return nr_moved; } static void shrink_active_list(unsigned long nr_to_scan, @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, LIST_HEAD(l_inactive); struct page *page; struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; - unsigned long nr_rotated = 0; + unsigned long nr_rotated = 0, nr_unevictable = 0; + unsigned long nr_freed, nr_deactivate, nr_activate; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); @@ -1935,6 +1943,7 @@ static void shrink_active_list(unsigned long nr_to_scan, if (unlikely(!page_evictable(page))) { putback_lru_page(page); + nr_unevictable++; continue; } @@ -1980,13 +1989,16 @@ static void shrink_active_list(unsigned long nr_to_scan, */ reclaim_stat->recent_rotated[file] += nr_rotated; - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); spin_unlock_irq(&pgdat->lru_lock); mem_cgroup_uncharge_list(&l_hold); - free_hot_cold_page_list(&l_hold, true); + nr_freed = free_hot_cold_page_list(&l_hold, true); + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_freed, + nr_unevictable, nr_deactivate, nr_rotated, + sc->priority, file); } /* -- 2.10.2 -- 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-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id 4A60E6B0260 for ; Wed, 28 Dec 2016 10:30:44 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id n3so34708237wjy.6 for ; Wed, 28 Dec 2016 07:30:44 -0800 (PST) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com. [74.125.82.66]) by mx.google.com with ESMTPS id p21si50706826wma.116.2016.12.28.07.30.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:43 -0800 (PST) Received: by mail-wm0-f66.google.com with SMTP id c85so24207576wmi.1 for ; Wed, 28 Dec 2016 07:30:42 -0800 (PST) From: Michal Hocko Subject: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Date: Wed, 28 Dec 2016 16:30:28 +0100 Message-Id: <20161228153032.10821-4-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko mm_vmscan_lru_isolate shows the number of requested, scanned and taken pages. This is mostly OK but on 32b systems the number of scanned pages is quite misleading because it includes both the scanned and skipped pages. Moreover the skipped part is scaled based on the number of taken pages. Let's report the exact numbers without any additional logic and add the number of skipped pages. This should make the reported data much more easier to interpret. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 8 ++++++-- mm/vmscan.c | 10 +++++----- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index d34cc0ced2be..6af4dae46db2 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -274,17 +274,19 @@ TRACE_EVENT(mm_vmscan_lru_isolate, int order, unsigned long nr_requested, unsigned long nr_scanned, + unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, int file), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), TP_STRUCT__entry( __field(int, classzone_idx) __field(int, order) __field(unsigned long, nr_requested) __field(unsigned long, nr_scanned) + __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) __field(int, file) @@ -295,17 +297,19 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->order = order; __entry->nr_requested = nr_requested; __entry->nr_scanned = nr_scanned; + __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; __entry->file = file; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", __entry->isolate_mode, __entry->classzone_idx, __entry->order, __entry->nr_requested, __entry->nr_scanned, + __entry->nr_skipped, __entry->nr_taken, __entry->file) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index 2302a1a58c6e..4f7c0d66d629 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, unsigned long nr_taken = 0; unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; + unsigned long skipped = 0, total_skipped = 0; unsigned long scan, nr_pages; LIST_HEAD(pages_skipped); @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, */ if (!list_empty(&pages_skipped)) { int zid; - unsigned long total_skipped = 0; for (zid = 0; zid < MAX_NR_ZONES; zid++) { if (!nr_skipped[zid]) continue; __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); - total_skipped += nr_skipped[zid]; + skipped += nr_skipped[zid]; } /* @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, * close to unreclaimable. If the LRU list is empty, account * skipped pages as a full scan. */ - scan += list_empty(src) ? total_skipped : total_skipped >> 2; + total_skipped = list_empty(src) ? skipped : skipped >> 2; list_splice(&pages_skipped, src); } - *nr_scanned = scan; + *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, is_file_lru(lru)); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.10.2 -- 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-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id D8F786B0266 for ; Wed, 28 Dec 2016 10:30:44 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id d17so24181802wjx.5 for ; Wed, 28 Dec 2016 07:30:44 -0800 (PST) Received: from mail-wj0-f194.google.com (mail-wj0-f194.google.com. [209.85.210.194]) by mx.google.com with ESMTPS id k24si50716659wmi.156.2016.12.28.07.30.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:43 -0800 (PST) Received: by mail-wj0-f194.google.com with SMTP id qs7so17130774wjc.1 for ; Wed, 28 Dec 2016 07:30:43 -0800 (PST) From: Michal Hocko Subject: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Wed, 28 Dec 2016 16:30:29 +0100 Message-Id: <20161228153032.10821-5-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is file or anonymous as well. Change the tracepoint to show symbolic names of the lru rather. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 20 ++++++++++++++------ mm/vmscan.c | 2 +- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 6af4dae46db2..cc0b4c456c78 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -36,6 +36,14 @@ (RECLAIM_WB_ASYNC) \ ) +#define show_lru_name(lru) \ + __print_symbolic(lru, \ + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) + TRACE_EVENT(mm_vmscan_kswapd_sleep, TP_PROTO(int nid), @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, - int file), + int lru), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), TP_STRUCT__entry( __field(int, classzone_idx) @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) - __field(int, file) + __field(int, lru) ), TP_fast_assign( @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; - __entry->file = file; + __entry->lru = lru; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", __entry->isolate_mode, __entry->classzone_idx, __entry->order, @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - __entry->file) + show_lru_name(__entry->lru)) ); TRACE_EVENT(mm_vmscan_writepage, diff --git a/mm/vmscan.c b/mm/vmscan.c index 4f7c0d66d629..3f0774f30a42 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - skipped, nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, lru); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.10.2 -- 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-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 0AAB06B0266 for ; Wed, 28 Dec 2016 10:30:46 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id i131so59422188wmf.3 for ; Wed, 28 Dec 2016 07:30:45 -0800 (PST) Received: from mail-wj0-f194.google.com (mail-wj0-f194.google.com. [209.85.210.194]) by mx.google.com with ESMTPS id x20si54420959wju.188.2016.12.28.07.30.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:44 -0800 (PST) Received: by mail-wj0-f194.google.com with SMTP id j10so54868560wjb.3 for ; Wed, 28 Dec 2016 07:30:44 -0800 (PST) From: Michal Hocko Subject: [PATCH 5/7] mm, vmscan: extract shrink_page_list reclaim counters into a struct Date: Wed, 28 Dec 2016 16:30:30 +0100 Message-Id: <20161228153032.10821-6-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko shrink_page_list returns quite some counters back to its caller. Extract the existing 5 into struct reclaim_stat because this makes the code easier to follow and also allows further counters to be returned. While we are at it, make all of them unsigned rather than unsigned long as we do not really need full 64b for them (we never scan more than SWAP_CLUSTER_MAX pages at once). This should reduce some stack space. This patch shouldn't introduce any functional change. Signed-off-by: Michal Hocko --- mm/vmscan.c | 61 ++++++++++++++++++++++++++++++------------------------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 3f0774f30a42..f6f2d828968c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -902,6 +902,14 @@ static void page_check_dirty_writeback(struct page *page, mapping->a_ops->is_dirty_writeback(page, dirty, writeback); } +struct reclaim_stat { + unsigned nr_dirty; + unsigned nr_unqueued_dirty; + unsigned nr_congested; + unsigned nr_writeback; + unsigned nr_immediate; +}; + /* * shrink_page_list() returns the number of reclaimed pages */ @@ -909,22 +917,18 @@ static unsigned long shrink_page_list(struct list_head *page_list, struct pglist_data *pgdat, struct scan_control *sc, enum ttu_flags ttu_flags, - unsigned long *ret_nr_dirty, - unsigned long *ret_nr_unqueued_dirty, - unsigned long *ret_nr_congested, - unsigned long *ret_nr_writeback, - unsigned long *ret_nr_immediate, + struct reclaim_stat *stat, bool force_reclaim) { LIST_HEAD(ret_pages); LIST_HEAD(free_pages); int pgactivate = 0; - unsigned long nr_unqueued_dirty = 0; - unsigned long nr_dirty = 0; - unsigned long nr_congested = 0; - unsigned long nr_reclaimed = 0; - unsigned long nr_writeback = 0; - unsigned long nr_immediate = 0; + unsigned nr_unqueued_dirty = 0; + unsigned nr_dirty = 0; + unsigned nr_congested = 0; + unsigned nr_reclaimed = 0; + unsigned nr_writeback = 0; + unsigned nr_immediate = 0; cond_resched(); @@ -1266,11 +1270,13 @@ static unsigned long shrink_page_list(struct list_head *page_list, list_splice(&ret_pages, page_list); count_vm_events(PGACTIVATE, pgactivate); - *ret_nr_dirty += nr_dirty; - *ret_nr_congested += nr_congested; - *ret_nr_unqueued_dirty += nr_unqueued_dirty; - *ret_nr_writeback += nr_writeback; - *ret_nr_immediate += nr_immediate; + if (stat) { + stat->nr_dirty = nr_dirty; + stat->nr_congested = nr_congested; + stat->nr_unqueued_dirty = nr_unqueued_dirty; + stat->nr_writeback = nr_writeback; + stat->nr_immediate = nr_immediate; + } return nr_reclaimed; } @@ -1282,7 +1288,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, .priority = DEF_PRIORITY, .may_unmap = 1, }; - unsigned long ret, dummy1, dummy2, dummy3, dummy4, dummy5; + unsigned long ret; struct page *page, *next; LIST_HEAD(clean_pages); @@ -1295,8 +1301,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, } ret = shrink_page_list(&clean_pages, zone->zone_pgdat, &sc, - TTU_UNMAP|TTU_IGNORE_ACCESS, - &dummy1, &dummy2, &dummy3, &dummy4, &dummy5, true); + TTU_UNMAP|TTU_IGNORE_ACCESS, NULL, true); list_splice(&clean_pages, page_list); mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_FILE, -ret); return ret; @@ -1696,11 +1701,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, unsigned long nr_scanned; unsigned long nr_reclaimed = 0; unsigned long nr_taken; - unsigned long nr_dirty = 0; - unsigned long nr_congested = 0; - unsigned long nr_unqueued_dirty = 0; - unsigned long nr_writeback = 0; - unsigned long nr_immediate = 0; + struct reclaim_stat stat = {}; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); @@ -1745,9 +1746,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, return 0; nr_reclaimed = shrink_page_list(&page_list, pgdat, sc, TTU_UNMAP, - &nr_dirty, &nr_unqueued_dirty, &nr_congested, - &nr_writeback, &nr_immediate, - false); + &stat, false); spin_lock_irq(&pgdat->lru_lock); @@ -1781,7 +1780,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * of pages under pages flagged for immediate reclaim and stall if any * are encountered in the nr_immediate check below. */ - if (nr_writeback && nr_writeback == nr_taken) + if (stat.nr_writeback && stat.nr_writeback == nr_taken) set_bit(PGDAT_WRITEBACK, &pgdat->flags); /* @@ -1793,7 +1792,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * Tag a zone as congested if all the dirty pages scanned were * backed by a congested BDI and wait_iff_congested will stall. */ - if (nr_dirty && nr_dirty == nr_congested) + if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested) set_bit(PGDAT_CONGESTED, &pgdat->flags); /* @@ -1802,7 +1801,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * the pgdat PGDAT_DIRTY and kswapd will start writing pages from * reclaim context. */ - if (nr_unqueued_dirty == nr_taken) + if (stat.nr_unqueued_dirty == nr_taken) set_bit(PGDAT_DIRTY, &pgdat->flags); /* @@ -1811,7 +1810,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * that pages are cycling through the LRU faster than * they are written so also forcibly stall. */ - if (nr_immediate && current_may_throttle()) + if (stat.nr_immediate && current_may_throttle()) congestion_wait(BLK_RW_ASYNC, HZ/10); } -- 2.10.2 -- 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-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id 2C2016B0267 for ; Wed, 28 Dec 2016 10:30:47 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id qs7so36453183wjc.4 for ; Wed, 28 Dec 2016 07:30:47 -0800 (PST) Received: from mail-wj0-f194.google.com (mail-wj0-f194.google.com. [209.85.210.194]) by mx.google.com with ESMTPS id c133si50713959wme.54.2016.12.28.07.30.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:45 -0800 (PST) Received: by mail-wj0-f194.google.com with SMTP id kp2so54789377wjc.0 for ; Wed, 28 Dec 2016 07:30:45 -0800 (PST) From: Michal Hocko Subject: [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint Date: Wed, 28 Dec 2016 16:30:31 +0100 Message-Id: <20161228153032.10821-7-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko mm_vmscan_lru_shrink_inactive will currently report the number of scanned and reclaimed pages. This doesn't give us an idea how the reclaim went except for the overall effectiveness though. Export and show other counters which will tell us why we couldn't reclaim some pages. - nr_dirty, nr_writeback, nr_congested and nr_immediate tells us how many pages are blocked due to IO - nr_activate tells us how many pages were moved to the active list - nr_ref_keep reports how many pages are kept on the LRU due to references (mostly for the file pages which are about to go for another round through the inactive list) - nr_unmap_fail - how many pages failed to unmap All these are rather low level so they might change in future but the tracepoint is already implementation specific so no tools should be depending on its stability. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 29 ++++++++++++++++++++++++++--- mm/vmscan.c | 14 ++++++++++++++ 2 files changed, 40 insertions(+), 3 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index cc0b4c456c78..d27606f27af7 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -348,14 +348,27 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_reclaimed, + unsigned long nr_dirty, unsigned long nr_writeback, + unsigned long nr_congested, unsigned long nr_immediate, + unsigned long nr_activate, unsigned long nr_ref_keep, + unsigned long nr_unmap_fail, int priority, int file), - TP_ARGS(nid, nr_scanned, nr_reclaimed, priority, file), + TP_ARGS(nid, nr_scanned, nr_reclaimed, nr_dirty, nr_writeback, + nr_congested, nr_immediate, nr_activate, nr_ref_keep, + nr_unmap_fail, priority, file), TP_STRUCT__entry( __field(int, nid) __field(unsigned long, nr_scanned) __field(unsigned long, nr_reclaimed) + __field(unsigned long, nr_dirty) + __field(unsigned long, nr_writeback) + __field(unsigned long, nr_congested) + __field(unsigned long, nr_immediate) + __field(unsigned long, nr_activate) + __field(unsigned long, nr_ref_keep) + __field(unsigned long, nr_unmap_fail) __field(int, priority) __field(int, reclaim_flags) ), @@ -364,14 +377,24 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, __entry->nid = nid; __entry->nr_scanned = nr_scanned; __entry->nr_reclaimed = nr_reclaimed; + __entry->nr_dirty = nr_dirty; + __entry->nr_writeback = nr_writeback; + __entry->nr_congested = nr_congested; + __entry->nr_immediate = nr_immediate; + __entry->nr_activate = nr_activate; + __entry->nr_ref_keep = nr_ref_keep; + __entry->nr_unmap_fail = nr_unmap_fail; __entry->priority = priority; __entry->reclaim_flags = trace_shrink_flags(file); ), - TP_printk("nid=%d nr_scanned=%ld nr_reclaimed=%ld priority=%d flags=%s", + TP_printk("nid=%d nr_scanned=%ld nr_reclaimed=%ld nr_dirty=%ld nr_writeback=%ld nr_congested=%ld nr_immediate=%ld nr_activate=%ld nr_ref_keep=%ld nr_unmap_fail=%ld priority=%d flags=%s", __entry->nid, __entry->nr_scanned, __entry->nr_reclaimed, - __entry->priority, + __entry->nr_dirty, __entry->nr_writeback, + __entry->nr_congested, __entry->nr_immediate, + __entry->nr_activate, __entry->nr_ref_keep, + __entry->nr_unmap_fail, __entry->priority, show_reclaim_flags(__entry->reclaim_flags)) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index f6f2d828968c..a701bdd6334a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -908,6 +908,9 @@ struct reclaim_stat { unsigned nr_congested; unsigned nr_writeback; unsigned nr_immediate; + unsigned nr_activate; + unsigned nr_ref_keep; + unsigned nr_unmap_fail; }; /* @@ -929,6 +932,8 @@ static unsigned long shrink_page_list(struct list_head *page_list, unsigned nr_reclaimed = 0; unsigned nr_writeback = 0; unsigned nr_immediate = 0; + unsigned nr_ref_keep = 0; + unsigned nr_unmap_fail = 0; cond_resched(); @@ -1067,6 +1072,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, case PAGEREF_ACTIVATE: goto activate_locked; case PAGEREF_KEEP: + nr_ref_keep++; goto keep_locked; case PAGEREF_RECLAIM: case PAGEREF_RECLAIM_CLEAN: @@ -1104,6 +1110,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, (ttu_flags | TTU_BATCH_FLUSH | TTU_LZFREE) : (ttu_flags | TTU_BATCH_FLUSH))) { case SWAP_FAIL: + nr_unmap_fail++; goto activate_locked; case SWAP_AGAIN: goto keep_locked; @@ -1276,6 +1283,9 @@ static unsigned long shrink_page_list(struct list_head *page_list, stat->nr_unqueued_dirty = nr_unqueued_dirty; stat->nr_writeback = nr_writeback; stat->nr_immediate = nr_immediate; + stat->nr_activate = pgactivate; + stat->nr_ref_keep = nr_ref_keep; + stat->nr_unmap_fail = nr_unmap_fail; } return nr_reclaimed; } @@ -1825,6 +1835,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id, nr_scanned, nr_reclaimed, + stat.nr_dirty, stat.nr_writeback, + stat.nr_congested, stat.nr_immediate, + stat.nr_activate, stat.nr_ref_keep, + stat.nr_unmap_fail, sc->priority, file); return nr_reclaimed; } -- 2.10.2 -- 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-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 457AA6B0268 for ; Wed, 28 Dec 2016 10:30:48 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id s63so59176589wms.7 for ; Wed, 28 Dec 2016 07:30:48 -0800 (PST) Received: from mail-wj0-f193.google.com (mail-wj0-f193.google.com. [209.85.210.193]) by mx.google.com with ESMTPS id kn2si54418779wjc.158.2016.12.28.07.30.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:30:46 -0800 (PST) Received: by mail-wj0-f193.google.com with SMTP id hb5so21632353wjc.2 for ; Wed, 28 Dec 2016 07:30:46 -0800 (PST) From: Michal Hocko Subject: [PATCH 7/7] mm, vmscan: add mm_vmscan_inactive_list_is_low tracepoint Date: Wed, 28 Dec 2016 16:30:32 +0100 Message-Id: <20161228153032.10821-8-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Michal Hocko Currently we have tracepoints for both active and inactive LRU lists reclaim but we do not have any which would tell us why we we decided to age the active list. Without that it is quite hard to diagnose active/inactive lists balancing. Add mm_vmscan_inactive_list_is_low tracepoint to tell us this information. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 40 ++++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 23 ++++++++++++++--------- 2 files changed, 54 insertions(+), 9 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index d27606f27af7..02c038c570a9 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -15,6 +15,7 @@ #define RECLAIM_WB_MIXED 0x0010u #define RECLAIM_WB_SYNC 0x0004u /* Unused, all reclaim async */ #define RECLAIM_WB_ASYNC 0x0008u +#define RECLAIM_WB_LRU (RECLAIM_WB_ANON|RECLAIM_WB_FILE) #define show_reclaim_flags(flags) \ (flags) ? __print_flags(flags, "|", \ @@ -436,6 +437,45 @@ TRACE_EVENT(mm_vmscan_lru_shrink_active, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_vmscan_inactive_list_is_low, + + TP_PROTO(int nid, int reclaim_idx, + unsigned long total_inactive, unsigned long inactive, + unsigned long total_active, unsigned long active, + unsigned long ratio, int file), + + TP_ARGS(nid, reclaim_idx, total_inactive, inactive, total_active, active, ratio, file), + + TP_STRUCT__entry( + __field(int, nid) + __field(int, reclaim_idx) + __field(unsigned long, total_inactive) + __field(unsigned long, inactive) + __field(unsigned long, total_active) + __field(unsigned long, active) + __field(unsigned long, ratio) + __field(int, reclaim_flags) + ), + + TP_fast_assign( + __entry->nid = nid; + __entry->reclaim_idx = reclaim_idx; + __entry->total_inactive = total_inactive; + __entry->inactive = inactive; + __entry->total_active = total_active; + __entry->active = active; + __entry->ratio = ratio; + __entry->reclaim_flags = trace_shrink_flags(file) & RECLAIM_WB_LRU; + ), + + TP_printk("nid=%d reclaim_idx=%d total_inactive=%ld inactive=%ld total_active=%ld active=%ld ratio=%ld flags=%s", + __entry->nid, + __entry->reclaim_idx, + __entry->total_inactive, __entry->inactive, + __entry->total_active, __entry->active, + __entry->ratio, + show_reclaim_flags(__entry->reclaim_flags)) +); #endif /* _TRACE_VMSCAN_H */ /* This part must be outside protection */ diff --git a/mm/vmscan.c b/mm/vmscan.c index a701bdd6334a..8021401213e0 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2041,11 +2041,11 @@ static void shrink_active_list(unsigned long nr_to_scan, * 10TB 320 32GB */ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, - struct scan_control *sc) + struct scan_control *sc, bool trace) { unsigned long inactive_ratio; - unsigned long inactive; - unsigned long active; + unsigned long total_inactive, inactive; + unsigned long total_active, active; unsigned long gb; struct pglist_data *pgdat = lruvec_pgdat(lruvec); int zid; @@ -2057,8 +2057,8 @@ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, if (!file && !total_swap_pages) return false; - inactive = lruvec_lru_size(lruvec, file * LRU_FILE); - active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE); + total_inactive = inactive = lruvec_lru_size(lruvec, file * LRU_FILE); + total_active = active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE); /* * For zone-constrained allocations, it is necessary to check if @@ -2087,6 +2087,11 @@ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, else inactive_ratio = 1; + if (trace) + trace_mm_vmscan_inactive_list_is_low(pgdat->node_id, + sc->reclaim_idx, + total_inactive, inactive, + total_active, active, inactive_ratio, file); return inactive * inactive_ratio < active; } @@ -2094,7 +2099,7 @@ static unsigned long shrink_list(enum lru_list lru, unsigned long nr_to_scan, struct lruvec *lruvec, struct scan_control *sc) { if (is_active_lru(lru)) { - if (inactive_list_is_low(lruvec, is_file_lru(lru), sc)) + if (inactive_list_is_low(lruvec, is_file_lru(lru), sc, true)) shrink_active_list(nr_to_scan, lruvec, sc, lru); return 0; } @@ -2225,7 +2230,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, * lruvec even if it has plenty of old anonymous pages unless the * system is under heavy pressure. */ - if (!inactive_list_is_low(lruvec, true, sc) && + if (!inactive_list_is_low(lruvec, true, sc, false) && lruvec_lru_size(lruvec, LRU_INACTIVE_FILE) >> sc->priority) { scan_balance = SCAN_FILE; goto out; @@ -2450,7 +2455,7 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc * Even if we did not try to evict anon pages at all, we want to * rebalance the anon lru active/inactive ratio. */ - if (inactive_list_is_low(lruvec, false, sc)) + if (inactive_list_is_low(lruvec, false, sc, true)) shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); } @@ -3100,7 +3105,7 @@ static void age_active_anon(struct pglist_data *pgdat, do { struct lruvec *lruvec = mem_cgroup_lruvec(pgdat, memcg); - if (inactive_list_is_low(lruvec, false, sc)) + if (inactive_list_is_low(lruvec, false, sc, true)) shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); -- 2.10.2 -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id 591976B0069 for ; Wed, 28 Dec 2016 10:50:35 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id hb5so90457942wjc.2 for ; Wed, 28 Dec 2016 07:50:35 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com. [2a00:1450:400c:c09::243]) by mx.google.com with ESMTPS id ri10si22760584wjb.215.2016.12.28.07.50.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 07:50:34 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id u144so62472273wmu.0 for ; Wed, 28 Dec 2016 07:50:33 -0800 (PST) Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> From: Nikolay Borisov Message-ID: Date: Wed, 28 Dec 2016 17:50:31 +0200 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko , linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko On 28.12.2016 17:30, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > -- 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-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id B68216B025E for ; Wed, 28 Dec 2016 11:00:33 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id s63so59281579wms.7 for ; Wed, 28 Dec 2016 08:00:33 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id ia3si54513070wjb.276.2016.12.28.08.00.32 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Dec 2016 08:00:32 -0800 (PST) Date: Wed, 28 Dec 2016 17:00:29 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161228160029.GF11470@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> 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: Nikolay Borisov Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: > > > On 28.12.2016 17:30, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? You are right. I will update the wording to: " mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is active or inactive as well as we use the same function to isolate pages for both of them. Change the tracepoint to show symbolic names of the lru rather. " Does it sound better? Thanks! -- Michal Hocko SUSE Labs -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id 5039F6B0069 for ; Wed, 28 Dec 2016 11:40:19 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id dh1so27708752wjb.0 for ; Wed, 28 Dec 2016 08:40:19 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com. [2a00:1450:400c:c09::242]) by mx.google.com with ESMTPS id 15si50833359wml.145.2016.12.28.08.40.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 08:40:18 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id l2so37204493wml.2 for ; Wed, 28 Dec 2016 08:40:18 -0800 (PST) Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161228160029.GF11470@dhcp22.suse.cz> From: Nikolay Borisov Message-ID: <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> Date: Wed, 28 Dec 2016 18:40:16 +0200 MIME-Version: 1.0 In-Reply-To: <20161228160029.GF11470@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On 28.12.2016 18:00, Michal Hocko wrote: > On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: >> >> >> On 28.12.2016 17:30, Michal Hocko wrote: >>> From: Michal Hocko >>> >>> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate >>> from is file or anonymous but we do not know which LRU this is. It is >>> useful to know whether the list is file or anonymous as well. Change >> >> Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? > > You are right. I will update the wording to: > " > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is active or inactive as well as we > use the same function to isolate pages for both of them. Change > the tracepoint to show symbolic names of the lru rather. > " > > Does it sound better? It's better. Just one more nit about the " as well as we use the same function to isolate pages for both of them" I think this can be reworded better. The way I understand is - it's better to know whether it's active/inactive since we are using the same function to do both, correct? If so then then perhaps the following is a bit more clear: " It is useful to know whether the list is active or inactive, since we are using the same function to isolate pages from both of them and it's hard to distinguish otherwise. " But as I said - it's a minor nit. > > 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-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 2E8476B0069 for ; Wed, 28 Dec 2016 11:49:56 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id qs7so36754056wjc.4 for ; Wed, 28 Dec 2016 08:49:56 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id w5si1712262wjs.173.2016.12.28.08.49.54 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Dec 2016 08:49:55 -0800 (PST) Date: Wed, 28 Dec 2016 17:49:52 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161228164952.GG11470@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161228160029.GF11470@dhcp22.suse.cz> <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Nikolay Borisov Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Wed 28-12-16 18:40:16, Nikolay Borisov wrote: [...] > " > It is useful to know whether the list is active or inactive, since we > are using the same function to isolate pages from both of them and it's > hard to distinguish otherwise. > " OK, updated. Thanks! -- Michal Hocko SUSE Labs -- 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-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 94FEB6B0069 for ; Thu, 29 Dec 2016 00:34:02 -0500 (EST) Received: by mail-pf0-f200.google.com with SMTP id j128so579994213pfg.4 for ; Wed, 28 Dec 2016 21:34:02 -0800 (PST) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id n1si52227975pgc.121.2016.12.28.21.34.00 for ; Wed, 28 Dec 2016 21:34:01 -0800 (PST) Date: Thu, 29 Dec 2016 14:33:59 +0900 From: Minchan Kim Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161229053359.GA1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161228153032.10821-3-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > From: Michal Hocko > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > the number of scanned, rotated, deactivated and freed pages from the > particular node's active list. > > Signed-off-by: Michal Hocko > --- > include/linux/gfp.h | 2 +- > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > mm/page_alloc.c | 6 +++++- > mm/vmscan.c | 22 +++++++++++++++++----- > 4 files changed, 61 insertions(+), 7 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 4175dca4ac39..61aa9b49e86d 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > extern void __free_pages(struct page *page, unsigned int order); > extern void free_pages(unsigned long addr, unsigned int order); > extern void free_hot_cold_page(struct page *page, bool cold); > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > struct page_frag_cache; > extern void __page_frag_drain(struct page *page, unsigned int order, > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 39bad8921ca1..d34cc0ced2be 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > show_reclaim_flags(__entry->reclaim_flags)) > ); > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > + > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > + unsigned long nr_unevictable, unsigned long nr_deactivated, > + unsigned long nr_rotated, int priority, int file), > + > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), I agree it is helpful. And it was when I investigated aging problem of 32bit when node-lru was introduced. However, the question is we really need all those kinds of information? just enough with nr_taken, nr_deactivated, priority, file? Also, look at minor thing below. Thanks. > + > + TP_STRUCT__entry( > + __field(int, nid) > + __field(unsigned long, nr_scanned) > + __field(unsigned long, nr_freed) > + __field(unsigned long, nr_unevictable) > + __field(unsigned long, nr_deactivated) > + __field(unsigned long, nr_rotated) > + __field(int, priority) > + __field(int, reclaim_flags) > + ), > + > + TP_fast_assign( > + __entry->nid = nid; > + __entry->nr_scanned = nr_scanned; > + __entry->nr_freed = nr_freed; > + __entry->nr_unevictable = nr_unevictable; > + __entry->nr_deactivated = nr_deactivated; > + __entry->nr_rotated = nr_rotated; > + __entry->priority = priority; > + __entry->reclaim_flags = trace_shrink_flags(file); > + ), > + > + TP_printk("nid=%d nr_scanned=%ld nr_freed=%ld nr_unevictable=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", > + __entry->nid, > + __entry->nr_scanned, __entry->nr_freed, __entry->nr_unevictable, > + __entry->nr_deactivated, __entry->nr_rotated, > + __entry->priority, > + show_reclaim_flags(__entry->reclaim_flags)) > +); > + > #endif /* _TRACE_VMSCAN_H */ > > /* This part must be outside protection */ > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1c24112308d6..77d204660857 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2487,14 +2487,18 @@ void free_hot_cold_page(struct page *page, bool cold) > /* > * Free a list of 0-order pages > */ > -void free_hot_cold_page_list(struct list_head *list, bool cold) > +int free_hot_cold_page_list(struct list_head *list, bool cold) > { > struct page *page, *next; > + int ret = 0; > > list_for_each_entry_safe(page, next, list, lru) { > trace_mm_page_free_batched(page, cold); > free_hot_cold_page(page, cold); > + ret++; > } > + > + return ret; > } > > /* > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c4abf08861d2..2302a1a58c6e 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, > * > * The downside is that we have to touch page->_refcount against each page. > * But we had to alter page->flags anyway. > + * > + * Returns the number of pages moved to the given lru. > */ > > -static void move_active_pages_to_lru(struct lruvec *lruvec, > +static int move_active_pages_to_lru(struct lruvec *lruvec, > struct list_head *list, > struct list_head *pages_to_free, > enum lru_list lru) > @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > unsigned long pgmoved = 0; > struct page *page; > int nr_pages; > + int nr_moved = 0; > > while (!list_empty(list)) { > page = lru_to_page(list); > @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > spin_lock_irq(&pgdat->lru_lock); > } else > list_add(&page->lru, pages_to_free); > + } else { > + nr_moved++; > } > } > > if (!is_active_lru(lru)) > __count_vm_events(PGDEACTIVATE, pgmoved); > + > + return nr_moved; > } > > static void shrink_active_list(unsigned long nr_to_scan, > @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, > LIST_HEAD(l_inactive); > struct page *page; > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; > - unsigned long nr_rotated = 0; > + unsigned long nr_rotated = 0, nr_unevictable = 0; > + unsigned long nr_freed, nr_deactivate, nr_activate; > isolate_mode_t isolate_mode = 0; > int file = is_file_lru(lru); > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > @@ -1935,6 +1943,7 @@ static void shrink_active_list(unsigned long nr_to_scan, > > if (unlikely(!page_evictable(page))) { > putback_lru_page(page); > + nr_unevictable++; > continue; > } > > @@ -1980,13 +1989,16 @@ static void shrink_active_list(unsigned long nr_to_scan, > */ > reclaim_stat->recent_rotated[file] += nr_rotated; > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); Who use nr_active in here? > + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); > spin_unlock_irq(&pgdat->lru_lock); > > mem_cgroup_uncharge_list(&l_hold); > - free_hot_cold_page_list(&l_hold, true); > + nr_freed = free_hot_cold_page_list(&l_hold, true); > + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_freed, > + nr_unevictable, nr_deactivate, nr_rotated, > + sc->priority, file); > } > > /* > -- > 2.10.2 > > -- > 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-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 0FB616B0069 for ; Thu, 29 Dec 2016 00:53:35 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id n189so551420891pga.4 for ; Wed, 28 Dec 2016 21:53:35 -0800 (PST) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTP id d7si52345589plj.257.2016.12.28.21.53.33 for ; Wed, 28 Dec 2016 21:53:34 -0800 (PST) Date: Thu, 29 Dec 2016 14:53:29 +0900 From: Minchan Kim Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Message-ID: <20161229055329.GB1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko On Wed, Dec 28, 2016 at 04:30:28PM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate shows the number of requested, scanned and taken > pages. This is mostly OK but on 32b systems the number of scanned pages > is quite misleading because it includes both the scanned and skipped > pages. Moreover the skipped part is scaled based on the number of taken > pages. Let's report the exact numbers without any additional logic and > add the number of skipped pages. This should make the reported data much > more easier to interpret. > > Signed-off-by: Michal Hocko Acked-by: 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: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 53F406B0069 for ; Thu, 29 Dec 2016 01:02:07 -0500 (EST) Received: by mail-pf0-f198.google.com with SMTP id j128so580521516pfg.4 for ; Wed, 28 Dec 2016 22:02:07 -0800 (PST) Received: from lgeamrelo13.lge.com (LGEAMRELO13.lge.com. [156.147.23.53]) by mx.google.com with ESMTP id n22si52316526pfi.246.2016.12.28.22.02.05 for ; Wed, 28 Dec 2016 22:02:06 -0800 (PST) Date: Thu, 29 Dec 2016 15:02:04 +0900 From: Minchan Kim Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161229060204.GC1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko Not exactly same with this but idea is almost same. I used almost same tracepoint to investigate agging(i.e., deactivating) problem in 32b kernel with node-lru. It was enough. Namely, I didn't need tracepoint in shrink_active_list like your first patch. Your first patch is more straightforwad and information. But as you introduced this patch, I want to ask in here. Isn't it enough with this patch without your first one to find a such problem? Thanks. > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > -- > 2.10.2 > > -- > 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-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 0FBC16B0069 for ; Thu, 29 Dec 2016 02:33:20 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id c4so581442505pfb.7 for ; Wed, 28 Dec 2016 23:33:20 -0800 (PST) Received: from out4440.biz.mail.alibaba.com (out4440.biz.mail.alibaba.com. [47.88.44.40]) by mx.google.com with ESMTP id 128si20881288pgg.245.2016.12.28.23.33.17 for ; Wed, 28 Dec 2016 23:33:19 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-2-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-2-mhocko@kernel.org> Subject: Re: [PATCH 1/7] mm, vmscan: remove unused mm_vmscan_memcg_isolate Date: Thu, 29 Dec 2016 15:33:01 +0800 Message-ID: <06d201d261a5$c9248e80$5b6dab80$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > the trace point is not used since 925b7673cce3 ("mm: make per-memcg LRU > lists exclusive") so it can be removed. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 8C12D6B0069 for ; Thu, 29 Dec 2016 02:44:13 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id a190so858968978pgc.0 for ; Wed, 28 Dec 2016 23:44:13 -0800 (PST) Received: from out0-139.mail.aliyun.com (out0-139.mail.aliyun.com. [140.205.0.139]) by mx.google.com with ESMTP id t3si21431140plj.319.2016.12.28.23.44.12 for ; Wed, 28 Dec 2016 23:44:12 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-3-mhocko@kernel.org> Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Thu, 29 Dec 2016 15:44:06 +0800 Message-ID: <06d301d261a7$558f8ef0$00aeacd0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > the number of scanned, rotated, deactivated and freed pages from the > particular node's active list. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 43BFB6B0069 for ; Thu, 29 Dec 2016 02:50:08 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id u5so521888583pgi.7 for ; Wed, 28 Dec 2016 23:50:08 -0800 (PST) Received: from out4433.biz.mail.alibaba.com (out4433.biz.mail.alibaba.com. [47.88.44.33]) by mx.google.com with ESMTP id m66si52616348pfc.209.2016.12.28.23.50.06 for ; Wed, 28 Dec 2016 23:50:07 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Date: Thu, 29 Dec 2016 15:49:45 +0800 Message-ID: <06d701d261a8$20082390$60186ab0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate shows the number of requested, scanned and taken > pages. This is mostly OK but on 32b systems the number of scanned pages > is quite misleading because it includes both the scanned and skipped > pages. Moreover the skipped part is scaled based on the number of taken > pages. Let's report the exact numbers without any additional logic and > add the number of skipped pages. This should make the reported data much > more easier to interpret. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-wj0-f197.google.com (mail-wj0-f197.google.com [209.85.210.197]) by kanga.kvack.org (Postfix) with ESMTP id 55EC76B0069 for ; Thu, 29 Dec 2016 02:52:50 -0500 (EST) Received: by mail-wj0-f197.google.com with SMTP id n3so37433159wjy.6 for ; Wed, 28 Dec 2016 23:52:50 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id wf7si26720281wjb.193.2016.12.28.23.52.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Dec 2016 23:52:49 -0800 (PST) Date: Thu, 29 Dec 2016 08:52:46 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161229075243.GA29208@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229053359.GA1815@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Thu 29-12-16 14:33:59, Minchan Kim wrote: > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Our reclaim process has several tracepoints to tell us more about how > > things are progressing. We are, however, missing a tracepoint to track > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > the number of scanned, rotated, deactivated and freed pages from the > > particular node's active list. > > > > Signed-off-by: Michal Hocko > > --- > > include/linux/gfp.h | 2 +- > > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > > mm/page_alloc.c | 6 +++++- > > mm/vmscan.c | 22 +++++++++++++++++----- > > 4 files changed, 61 insertions(+), 7 deletions(-) > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > index 4175dca4ac39..61aa9b49e86d 100644 > > --- a/include/linux/gfp.h > > +++ b/include/linux/gfp.h > > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > > extern void __free_pages(struct page *page, unsigned int order); > > extern void free_pages(unsigned long addr, unsigned int order); > > extern void free_hot_cold_page(struct page *page, bool cold); > > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > > > struct page_frag_cache; > > extern void __page_frag_drain(struct page *page, unsigned int order, > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 39bad8921ca1..d34cc0ced2be 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > > show_reclaim_flags(__entry->reclaim_flags)) > > ); > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > + > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > + unsigned long nr_rotated, int priority, int file), > > + > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > I agree it is helpful. And it was when I investigated aging problem of 32bit > when node-lru was introduced. However, the question is we really need all those > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? Dunno. Is it harmful to add this information? I like it more when the numbers just add up and you have a clear picture. You never know what might be useful when debugging a weird behavior. [...] > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > > Who use nr_active in here? this is an omission. I just forgot to add it... Thanks for noticing. -- Michal Hocko SUSE Labs -- 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-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 899F86B0253 for ; Thu, 29 Dec 2016 02:54:06 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id g1so910998448pgn.3 for ; Wed, 28 Dec 2016 23:54:06 -0800 (PST) Received: from out4433.biz.mail.alibaba.com (out4433.biz.mail.alibaba.com. [47.88.44.33]) by mx.google.com with ESMTP id 33si20463148pll.186.2016.12.28.23.54.04 for ; Wed, 28 Dec 2016 23:54:05 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Thu, 29 Dec 2016 15:53:49 +0800 Message-ID: <06d801d261a8$b1763600$1462a200$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) by kanga.kvack.org (Postfix) with ESMTP id 0F2836B0069 for ; Thu, 29 Dec 2016 02:56:54 -0500 (EST) Received: by mail-ua0-f200.google.com with SMTP id 2so63676921uax.4 for ; Wed, 28 Dec 2016 23:56:54 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id h125si27338551wme.3.2016.12.28.23.56.52 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Dec 2016 23:56:52 -0800 (PST) Date: Thu, 29 Dec 2016 08:56:49 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161229075649.GB29208@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229060204.GC1815@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Thu 29-12-16 15:02:04, Minchan Kim wrote: > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > the tracepoint to show symbolic names of the lru rather. > > > > Signed-off-by: Michal Hocko > > Not exactly same with this but idea is almost same. > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > in 32b kernel with node-lru. > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > first patch. > Your first patch is more straightforwad and information. But as you introduced > this patch, I want to ask in here. > Isn't it enough with this patch without your first one to find a such problem? I assume this should be a reply to http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? And you are right that for the particular problem it was enough to have a tracepoint inside inactive_list_is_low and shrink_active_list one wasn't really needed. On the other hand aging issues are really hard to debug as well and so I think that both are useful. The first one tell us _why_ we do aging while the later _how_ we do that. -- Michal Hocko SUSE Labs -- 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-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 2D2956B025E for ; Thu, 29 Dec 2016 03:00:52 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id n189so557077295pga.4 for ; Thu, 29 Dec 2016 00:00:52 -0800 (PST) Received: from out4433.biz.mail.alibaba.com (out4433.biz.mail.alibaba.com. [47.88.44.33]) by mx.google.com with ESMTP id y61si21841228plh.236.2016.12.29.00.00.49 for ; Thu, 29 Dec 2016 00:00:51 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-6-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-6-mhocko@kernel.org> Subject: Re: [PATCH 5/7] mm, vmscan: extract shrink_page_list reclaim counters into a struct Date: Thu, 29 Dec 2016 16:00:33 +0800 Message-ID: <06d901d261a9$a2277d70$e6767850$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > shrink_page_list returns quite some counters back to its caller. Extract > the existing 5 into struct reclaim_stat because this makes the code > easier to follow and also allows further counters to be returned. > > While we are at it, make all of them unsigned rather than unsigned long > as we do not really need full 64b for them (we never scan more than > SWAP_CLUSTER_MAX pages at once). This should reduce some stack space. > > This patch shouldn't introduce any functional change. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id AA8736B025E for ; Thu, 29 Dec 2016 03:06:06 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id b1so954059068pgc.5 for ; Thu, 29 Dec 2016 00:06:06 -0800 (PST) Received: from out4435.biz.mail.alibaba.com (out4435.biz.mail.alibaba.com. [47.88.44.35]) by mx.google.com with ESMTP id 15si52738163pfk.17.2016.12.29.00.06.04 for ; Thu, 29 Dec 2016 00:06:05 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-7-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-7-mhocko@kernel.org> Subject: Re: [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint Date: Thu, 29 Dec 2016 16:05:49 +0800 Message-ID: <06da01d261aa$5e7b01e0$1b7105a0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_shrink_inactive will currently report the number of > scanned and reclaimed pages. This doesn't give us an idea how the > reclaim went except for the overall effectiveness though. Export > and show other counters which will tell us why we couldn't reclaim > some pages. > - nr_dirty, nr_writeback, nr_congested and nr_immediate tells > us how many pages are blocked due to IO > - nr_activate tells us how many pages were moved to the active > list > - nr_ref_keep reports how many pages are kept on the LRU due > to references (mostly for the file pages which are about to > go for another round through the inactive list) > - nr_unmap_fail - how many pages failed to unmap > > All these are rather low level so they might change in future but the > tracepoint is already implementation specific so no tools should be > depending on its stability. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 82DC86B0069 for ; Thu, 29 Dec 2016 03:29:46 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id u5so523804324pgi.7 for ; Thu, 29 Dec 2016 00:29:46 -0800 (PST) Received: from out4433.biz.mail.alibaba.com (out4433.biz.mail.alibaba.com. [47.88.44.33]) by mx.google.com with ESMTP id f3si6778963pga.210.2016.12.29.00.29.44 for ; Thu, 29 Dec 2016 00:29:45 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-8-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-8-mhocko@kernel.org> Subject: Re: [PATCH 7/7] mm, vmscan: add mm_vmscan_inactive_list_is_low tracepoint Date: Thu, 29 Dec 2016 16:19:25 +0800 Message-ID: <06db01d261ac$44a57910$cdf06b30$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , linux-mm@kvack.org Cc: 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' , 'Michal Hocko' On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > Currently we have tracepoints for both active and inactive LRU lists > reclaim but we do not have any which would tell us why we we decided to > age the active list. Without that it is quite hard to diagnose > active/inactive lists balancing. Add mm_vmscan_inactive_list_is_low > tracepoint to tell us this information. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton -- 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-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 557476B0038 for ; Thu, 29 Dec 2016 20:48:56 -0500 (EST) Received: by mail-pf0-f200.google.com with SMTP id j128so608797004pfg.4 for ; Thu, 29 Dec 2016 17:48:56 -0800 (PST) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTP id u189si55253513pfu.124.2016.12.29.17.48.54 for ; Thu, 29 Dec 2016 17:48:55 -0800 (PST) Date: Fri, 30 Dec 2016 10:48:53 +0900 From: Minchan Kim Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230014853.GA4184@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229075243.GA29208@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > things are progressing. We are, however, missing a tracepoint to track > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > the number of scanned, rotated, deactivated and freed pages from the > > > particular node's active list. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > include/linux/gfp.h | 2 +- > > > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > > > mm/page_alloc.c | 6 +++++- > > > mm/vmscan.c | 22 +++++++++++++++++----- > > > 4 files changed, 61 insertions(+), 7 deletions(-) > > > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > > index 4175dca4ac39..61aa9b49e86d 100644 > > > --- a/include/linux/gfp.h > > > +++ b/include/linux/gfp.h > > > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > > > extern void __free_pages(struct page *page, unsigned int order); > > > extern void free_pages(unsigned long addr, unsigned int order); > > > extern void free_hot_cold_page(struct page *page, bool cold); > > > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > > > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > > > > > struct page_frag_cache; > > > extern void __page_frag_drain(struct page *page, unsigned int order, > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 39bad8921ca1..d34cc0ced2be 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > > > show_reclaim_flags(__entry->reclaim_flags)) > > > ); > > > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > + > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > + unsigned long nr_rotated, int priority, int file), > > > + > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > when node-lru was introduced. However, the question is we really need all those > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > Dunno. Is it harmful to add this information? I like it more when the > numbers just add up and you have a clear picture. You never know what > might be useful when debugging a weird behavior. Michal, I'm not huge fan of "might be useful" although it's a small piece of code. It adds just all of kinds overheads (memory footprint, runtime performance, maintainance) without any proved benefit. If we allow such things, people would start adding more things with just "why not, it might be useful. you never know the future" and it ends up making linux fiction novel mess. If it's necessary, someday, someone will catch up and will send or ask patch with detailed description "why the stat is important and how it is good for us to solve some problem". From that, we can learn workload, way to solve the problem and git history has the valuable description so new comers can keep the community up easily. So, finally, overheads are justified and get merged. Please add must-have for your goal described. -- 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-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 839DA6B0038 for ; Thu, 29 Dec 2016 20:56:27 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id n189so614696918pga.4 for ; Thu, 29 Dec 2016 17:56:27 -0800 (PST) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id u6si22058874plj.120.2016.12.29.17.56.26 for ; Thu, 29 Dec 2016 17:56:26 -0800 (PST) Date: Fri, 30 Dec 2016 10:56:25 +0900 From: Minchan Kim Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161230015625.GB4184@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> <20161229075649.GB29208@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229075649.GB29208@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote: > On Thu 29-12-16 15:02:04, Minchan Kim wrote: > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > from is file or anonymous but we do not know which LRU this is. It is > > > useful to know whether the list is file or anonymous as well. Change > > > the tracepoint to show symbolic names of the lru rather. > > > > > > Signed-off-by: Michal Hocko > > > > Not exactly same with this but idea is almost same. > > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > > in 32b kernel with node-lru. > > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > > first patch. > > Your first patch is more straightforwad and information. But as you introduced > > this patch, I want to ask in here. > > Isn't it enough with this patch without your first one to find a such problem? > > I assume this should be a reply to > http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? I don't know my browser says "No such Message-ID known" > And you are right that for the particular problem it was enough to have > a tracepoint inside inactive_list_is_low and shrink_active_list one > wasn't really needed. On the other hand aging issues are really hard to What kinds of aging issue? What's the problem? How such tracepoint can help? Please describe. > debug as well and so I think that both are useful. The first one tell us > _why_ we do aging while the later _how_ we do that. Solve reported problem first you already knew. It would be no doubt to merge and then send other patches about "it might be useful" with useful scenario. -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id 502016B0038 for ; Fri, 30 Dec 2016 04:11:21 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id iq1so36504748wjb.1 for ; Fri, 30 Dec 2016 01:11:21 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id ho7si61489649wjb.275.2016.12.30.01.11.19 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 01:11:19 -0800 (PST) Date: Fri, 30 Dec 2016 09:11:17 +0000 From: Mel Gorman Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230091117.nkxn3bnhle3bofhw@suse.de> References: <20161228153032.10821-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > Hi, > while debugging [1] I've realized that there is some room for > improvements in the tracepoints set we offer currently. I had hard times > to make any conclusion from the existing ones. The resulting problem > turned out to be active list aging [2] and we are missing at least two > tracepoints to debug such a problem. > > Some existing tracepoints could export more information to see _why_ the > reclaim progress cannot be made not only _how much_ we could reclaim. > The later could be seen quite reasonably from the vmstat counters > already. It can be argued that we are showing too many implementation > details in those tracepoints but I consider them way too lowlevel > already to be usable by any kernel independent userspace. I would be > _really_ surprised if anything but debugging tools have used them. > > Any feedback is highly appreciated. > There is some minor overhead introduced in some paths regardless of whether the tracepoints are active or not but I suspect it's negligible in the context of the overhead of reclaim in general so; Acked-by: Mel Gorman -- Mel Gorman SUSE Labs -- 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-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 5D9A16B025E for ; Fri, 30 Dec 2016 04:26:42 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id d17so31532732wjx.5 for ; Fri, 30 Dec 2016 01:26:42 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id iu2si61458334wjb.280.2016.12.30.01.26.40 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 01:26:40 -0800 (PST) Date: Fri, 30 Dec 2016 10:26:37 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230092636.GA13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230014853.GA4184@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim , Hillf Danton Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri 30-12-16 10:48:53, Minchan Kim wrote: > On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: [...] > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > > + > > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > > + unsigned long nr_rotated, int priority, int file), > > > > + > > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > > when node-lru was introduced. However, the question is we really need all those > > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > > > Dunno. Is it harmful to add this information? I like it more when the > > numbers just add up and you have a clear picture. You never know what > > might be useful when debugging a weird behavior. > > Michal, I'm not huge fan of "might be useful" although it's a small piece of code. But these are tracepoints. One of their primary reasons to exist is to help debug things. And it is really hard to predict what might be useful in advance. It is not like the patch would export numbers which would be irrelevant to the reclaim. > It adds just all of kinds overheads (memory footprint, runtime performance, > maintainance) without any proved benefit. Does it really add any measurable overhead or the maintenance burden? I think the only place we could argue about is free_hot_cold_page_list which is used in hot paths. I think we can sacrifice it. The same for culled unevictable pages. We wouldn't know what is the missing part nr_taken-(nr_activate+nr_deactivate) because it could be either freed or moved to the unevictable list but that could be handled in a separate tracepoint in putback_lru_page which sounds like a useful thing I guess. > If we allow such things, people would start adding more things with just "why not, > it might be useful. you never know the future" and it ends up making linux fiction > novel mess. I agree with this concern in general, but is this the case in this particular case? > If it's necessary, someday, someone will catch up and will send or ask patch with > detailed description "why the stat is important and how it is good for us to solve > some problem". I can certainly enhance the changelog. See below. > From that, we can learn workload, way to solve the problem and git > history has the valuable description so new comers can keep the community up easily. > So, finally, overheads are justified and get merged. > > Please add must-have for your goal described. My primary point is that tracepoints which do not give us a good picture are quite useless and force us to add trace_printk or other means to give us further information. Then I wonder why to have an incomplete tracepoint at all. Anyway, what do you think about this updated patch? I have kept Hillf's A-b so please let me know if it is no longer valid. --- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 2EAA36B025E for ; Fri, 30 Dec 2016 04:33:14 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id d17so31555001wjx.5 for ; Fri, 30 Dec 2016 01:33:14 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 203si57821354wmh.55.2016.12.30.01.33.12 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 01:33:12 -0800 (PST) Date: Fri, 30 Dec 2016 10:33:10 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161230093308.GB13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> <20161229075649.GB29208@dhcp22.suse.cz> <20161230015625.GB4184@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230015625.GB4184@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri 30-12-16 10:56:25, Minchan Kim wrote: > On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote: > > On Thu 29-12-16 15:02:04, Minchan Kim wrote: > > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > > from is file or anonymous but we do not know which LRU this is. It is > > > > useful to know whether the list is file or anonymous as well. Change > > > > the tracepoint to show symbolic names of the lru rather. > > > > > > > > Signed-off-by: Michal Hocko > > > > > > Not exactly same with this but idea is almost same. > > > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > > > in 32b kernel with node-lru. > > > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > > > first patch. > > > Your first patch is more straightforwad and information. But as you introduced > > > this patch, I want to ask in here. > > > Isn't it enough with this patch without your first one to find a such problem? > > > > I assume this should be a reply to > > http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? > > I don't know my browser says "No such Message-ID known" Hmm, not sure why it didn't get archived at lkml.kernel.org. I meant https://lkml.org/lkml/2016/12/28/167 > > And you are right that for the particular problem it was enough to have > > a tracepoint inside inactive_list_is_low and shrink_active_list one > > wasn't really needed. On the other hand aging issues are really hard to > > What kinds of aging issue? What's the problem? How such tracepoint can help? > Please describe. If you do not see that active list is shrunk then you do not know why it is not shrunk. It might be a active/inactive ratio or just a plan bug like the 32b issue me and you were debugging. > > debug as well and so I think that both are useful. The first one tell us > > _why_ we do aging while the later _how_ we do that. > > Solve reported problem first you already knew. It would be no doubt > to merge and then send other patches about "it might be useful" with > useful scenario. I am not sure I understand. The point of tracepoints is to be pro-actively helpful not only to add something that has been useful in one-off cases. A particular debugging session might be really helpful to tell us what we are missing and this was the case here to a large part. Once I was looking there I just wanted to save the pain of adding more debugging information in future and allow people to debug their issue without forcing them to recompile the kernel. I believe this is one of the strong usecases for tracepoints in the first place. -- Michal Hocko SUSE Labs -- 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-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 2D6B16B0038 for ; Fri, 30 Dec 2016 04:36:59 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id c85so34908213wmi.6 for ; Fri, 30 Dec 2016 01:36:59 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id yr4si61542378wjc.210.2016.12.30.01.36.57 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 01:36:57 -0800 (PST) Date: Fri, 30 Dec 2016 10:36:55 +0100 From: Michal Hocko Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230093654.GC13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161230091117.nkxn3bnhle3bofhw@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230091117.nkxn3bnhle3bofhw@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri 30-12-16 09:11:17, Mel Gorman wrote: > On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > > Hi, > > while debugging [1] I've realized that there is some room for > > improvements in the tracepoints set we offer currently. I had hard times > > to make any conclusion from the existing ones. The resulting problem > > turned out to be active list aging [2] and we are missing at least two > > tracepoints to debug such a problem. > > > > Some existing tracepoints could export more information to see _why_ the > > reclaim progress cannot be made not only _how much_ we could reclaim. > > The later could be seen quite reasonably from the vmstat counters > > already. It can be argued that we are showing too many implementation > > details in those tracepoints but I consider them way too lowlevel > > already to be usable by any kernel independent userspace. I would be > > _really_ surprised if anything but debugging tools have used them. > > > > Any feedback is highly appreciated. > > > > There is some minor overhead introduced in some paths regardless of > whether the tracepoints are active or not but I suspect it's negligible > in the context of the overhead of reclaim in general so; I will work on improving some of them. E.g. I've dropped the change to free_hot_cold_page_list because that is indeed a hot path but other than that there shouldn't be any even medium hot path which should see any overhead I can see. If you are aware of any, please let me know and I will think about how to improve it. > Acked-by: Mel Gorman Thanks! -- Michal Hocko SUSE Labs -- 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-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id AA9106B0038 for ; Fri, 30 Dec 2016 04:38:47 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id u5so601677194pgi.7 for ; Fri, 30 Dec 2016 01:38:47 -0800 (PST) Received: from out4440.biz.mail.alibaba.com (out4440.biz.mail.alibaba.com. [47.88.44.40]) by mx.google.com with ESMTP id n77si24447624pfj.225.2016.12.30.01.38.45 for ; Fri, 30 Dec 2016 01:38:46 -0800 (PST) Reply-To: "Hillf Danton" From: "Hillf Danton" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> In-Reply-To: <20161230092636.GA13301@dhcp22.suse.cz> Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Fri, 30 Dec 2016 17:38:28 +0800 Message-ID: <001b01d26280$7a5ee120$6f1ca360$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Michal Hocko' , 'Minchan Kim' Cc: linux-mm@kvack.org, 'Andrew Morton' , 'Mel Gorman' , 'Johannes Weiner' , 'Vlastimil Babka' , 'Rik van Riel' , 'LKML' On Friday, December 30, 2016 5:27 PM Michal Hocko wrote: > Anyway, what do you think about this updated patch? I have kept Hillf's > A-b so please let me know if it is no longer valid. > My mind is not changed:) Happy new year folks! Hillf -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id 3A3136B0253 for ; Fri, 30 Dec 2016 05:20:48 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id iq1so36751743wjb.1 for ; Fri, 30 Dec 2016 02:20:48 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id oy7si61681572wjb.129.2016.12.30.02.20.47 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 02:20:47 -0800 (PST) Date: Fri, 30 Dec 2016 10:20:45 +0000 From: Mel Gorman Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230102045.y2fiszc2o2uqmny4@suse.de> References: <20161228153032.10821-1-mhocko@kernel.org> <20161230091117.nkxn3bnhle3bofhw@suse.de> <20161230093654.GC13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20161230093654.GC13301@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri, Dec 30, 2016 at 10:36:55AM +0100, Michal Hocko wrote: > On Fri 30-12-16 09:11:17, Mel Gorman wrote: > > On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > > > Hi, > > > while debugging [1] I've realized that there is some room for > > > improvements in the tracepoints set we offer currently. I had hard times > > > to make any conclusion from the existing ones. The resulting problem > > > turned out to be active list aging [2] and we are missing at least two > > > tracepoints to debug such a problem. > > > > > > Some existing tracepoints could export more information to see _why_ the > > > reclaim progress cannot be made not only _how much_ we could reclaim. > > > The later could be seen quite reasonably from the vmstat counters > > > already. It can be argued that we are showing too many implementation > > > details in those tracepoints but I consider them way too lowlevel > > > already to be usable by any kernel independent userspace. I would be > > > _really_ surprised if anything but debugging tools have used them. > > > > > > Any feedback is highly appreciated. > > > > > > > There is some minor overhead introduced in some paths regardless of > > whether the tracepoints are active or not but I suspect it's negligible > > in the context of the overhead of reclaim in general so; > > I will work on improving some of them. E.g. I've dropped the change to > free_hot_cold_page_list because that is indeed a hot path but other than > that there shouldn't be any even medium hot path which should see any > overhead I can see. If you are aware of any, please let me know and I > will think about how to improve it. > I didn't spot one. The path where I saw the most overhead is already quite heavy. -- Mel Gorman SUSE Labs -- 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-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id CBE1D6B0038 for ; Fri, 30 Dec 2016 11:05:04 -0500 (EST) Received: by mail-pf0-f197.google.com with SMTP id i88so613456817pfk.3 for ; Fri, 30 Dec 2016 08:05:04 -0800 (PST) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTP id u62si57274862pgc.183.2016.12.30.08.05.02 for ; Fri, 30 Dec 2016 08:05:03 -0800 (PST) Date: Sat, 31 Dec 2016 01:04:56 +0900 From: Minchan Kim Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230160456.GA7267@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230092636.GA13301@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri, Dec 30, 2016 at 10:26:37AM +0100, Michal Hocko wrote: > On Fri 30-12-16 10:48:53, Minchan Kim wrote: > > On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > > > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > [...] > > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > > > + > > > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > > > + unsigned long nr_rotated, int priority, int file), > > > > > + > > > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > > > when node-lru was introduced. However, the question is we really need all those > > > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > > > > > Dunno. Is it harmful to add this information? I like it more when the > > > numbers just add up and you have a clear picture. You never know what > > > might be useful when debugging a weird behavior. > > > > Michal, I'm not huge fan of "might be useful" although it's a small piece of code. > > But these are tracepoints. One of their primary reasons to exist is > to help debug things. And it is really hard to predict what might be > useful in advance. It is not like the patch would export numbers which > would be irrelevant to the reclaim. What's different? Please think over if everyone says like that they want to add something with the reason "it's tracepoint which helps dubug and we cannot assume what might be useful in the future." > > > It adds just all of kinds overheads (memory footprint, runtime performance, > > maintainance) without any proved benefit. > > Does it really add any measurable overhead or the maintenance burden? I Don't limit your thought in this particular case and expand the idea to others who want to see random value via tracepoint with just "might-be- good". We will lose the reason to prevent that trend if we merge any tracepoint expansion patch with just "might-be-useful" reason. Finally, that would bite us. > think the only place we could argue about is free_hot_cold_page_list > which is used in hot paths. The point of view about shrinking active list, what we want to know is just (nr_taken|nr_deactivated|priority|file) and it's enough, I think. So, if you want to add nr_freed, nr_unevictable, nr_rotated please, describe "what problem we can solve with those each numbers". > > I think we can sacrifice it. The same for culled unevictable > pages. We wouldn't know what is the missing part > nr_taken-(nr_activate+nr_deactivate) because it could be either freed or > moved to the unevictable list but that could be handled in a separate > tracepoint in putback_lru_page which sounds like a useful thing I guess. > > > If we allow such things, people would start adding more things with just "why not, > > it might be useful. you never know the future" and it ends up making linux fiction > > novel mess. > > I agree with this concern in general, but is this the case in this > particular case? I believe it's not different. > > > If it's necessary, someday, someone will catch up and will send or ask patch with > > detailed description "why the stat is important and how it is good for us to solve > > some problem". > > I can certainly enhance the changelog. See below. > > > From that, we can learn workload, way to solve the problem and git > > history has the valuable description so new comers can keep the community up easily. > > So, finally, overheads are justified and get merged. > > > > Please add must-have for your goal described. > > My primary point is that tracepoints which do not give us a good picture > are quite useless and force us to add trace_printk or other means to > give us further information. Then I wonder why to have an incomplete > tracepoint at all. > > Anyway, what do you think about this updated patch? I have kept Hillf's > A-b so please let me know if it is no longer valid. > --- > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 27 Dec 2016 13:18:20 +0100 > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports I agree this part. > the number of > - nr_scanned, nr_taken pages to tell us the LRU isolation > effectiveness. I agree nr_taken for knowing shrinking effectiveness but don't agree nr_scanned. If we want to know LRU isolation effectiveness with nr_scanned and nr_taken, isolate_lru_pages will do. > - nr_rotated pages which tells us that we are hitting referenced > pages which are deactivated. If this is a large part of the > reported nr_deactivated pages then the active list is too small It might be but not exactly. If your goal is to know LRU size, it can be done in get_scan_count. I tend to agree LRU size is helpful for performance analysis because decreased LRU size signals memory shortage then performance drop. > - nr_activated pages which tells us how many pages are keept on the kept > active list - mostly exec pages. A high number can indicate file-based exec pages > that we might be trashing on executables. And welcome to drop nr_unevictable, nr_freed. I will be off until next week monday so please understand if my response is slow. Thanks. > > Changes since v1 > - report nr_taken pages as per Minchan > - report nr_activated as per Minchan > - do not report nr_freed pages because that would add a tiny overhead to > free_hot_cold_page_list which is a hot path > - do not report nr_unevictable because we can report this number via a > different and more generic tracepoint in putback_lru_page > - fix move_active_pages_to_lru to report proper page count when we hit > into large pages > > Acked-by: Hillf Danton > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > mm/vmscan.c | 18 ++++++++++++++---- > 2 files changed, 52 insertions(+), 4 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 39bad8921ca1..f9ef242ece1b 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > show_reclaim_flags(__entry->reclaim_flags)) > ); > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > + > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_taken, > + unsigned long nr_activate, unsigned long nr_deactivated, > + unsigned long nr_rotated, int priority, int file), > + > + TP_ARGS(nid, nr_scanned, nr_taken, nr_activate, nr_deactivated, nr_rotated, priority, file), > + > + TP_STRUCT__entry( > + __field(int, nid) > + __field(unsigned long, nr_scanned) > + __field(unsigned long, nr_taken) > + __field(unsigned long, nr_activate) > + __field(unsigned long, nr_deactivated) > + __field(unsigned long, nr_rotated) > + __field(int, priority) > + __field(int, reclaim_flags) > + ), > + > + TP_fast_assign( > + __entry->nid = nid; > + __entry->nr_scanned = nr_scanned; > + __entry->nr_taken = nr_taken; > + __entry->nr_activate = nr_activate; > + __entry->nr_deactivated = nr_deactivated; > + __entry->nr_rotated = nr_rotated; > + __entry->priority = priority; > + __entry->reclaim_flags = trace_shrink_flags(file); > + ), > + > + TP_printk("nid=%d nr_scanned=%ld nr_taken=%ld nr_activated=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", > + __entry->nid, > + __entry->nr_scanned, __entry->nr_taken, > + __entry->nr_activate, __entry->nr_deactivated, __entry->nr_rotated, > + __entry->priority, > + show_reclaim_flags(__entry->reclaim_flags)) > +); > + > #endif /* _TRACE_VMSCAN_H */ > > /* This part must be outside protection */ > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c4abf08861d2..4da4d8d0496c 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, > * > * The downside is that we have to touch page->_refcount against each page. > * But we had to alter page->flags anyway. > + * > + * Returns the number of pages moved to the given lru. > */ > > -static void move_active_pages_to_lru(struct lruvec *lruvec, > +static unsigned move_active_pages_to_lru(struct lruvec *lruvec, > struct list_head *list, > struct list_head *pages_to_free, > enum lru_list lru) > @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > unsigned long pgmoved = 0; > struct page *page; > int nr_pages; > + int nr_moved = 0; > > while (!list_empty(list)) { > page = lru_to_page(list); > @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > spin_lock_irq(&pgdat->lru_lock); > } else > list_add(&page->lru, pages_to_free); > + } else { > + nr_moved += nr_pages; > } > } > > if (!is_active_lru(lru)) > __count_vm_events(PGDEACTIVATE, pgmoved); > + > + return nr_moved; > } > > static void shrink_active_list(unsigned long nr_to_scan, > @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, > LIST_HEAD(l_inactive); > struct page *page; > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; > - unsigned long nr_rotated = 0; > + unsigned nr_deactivate, nr_activate; > + unsigned nr_rotated = 0; > isolate_mode_t isolate_mode = 0; > int file = is_file_lru(lru); > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > @@ -1980,13 +1988,15 @@ static void shrink_active_list(unsigned long nr_to_scan, > */ > reclaim_stat->recent_rotated[file] += nr_rotated; > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); > spin_unlock_irq(&pgdat->lru_lock); > > mem_cgroup_uncharge_list(&l_hold); > free_hot_cold_page_list(&l_hold, true); > + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_taken, > + nr_activate, nr_deactivate, nr_rotated, sc->priority, file); > } > > /* > -- > 2.10.2 > > > -- > Michal Hocko > SUSE Labs > > -- > 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id DDAEB6B0038 for ; Fri, 30 Dec 2016 11:37:47 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id hb5so99236804wjc.2 for ; Fri, 30 Dec 2016 08:37:47 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 186si59180980wmu.126.2016.12.30.08.37.46 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 08:37:46 -0800 (PST) Date: Fri, 30 Dec 2016 17:37:42 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230163742.GK13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230160456.GA7267@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Sat 31-12-16 01:04:56, Minchan Kim wrote: [...] > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > Our reclaim process has several tracepoints to tell us more about how > > things are progressing. We are, however, missing a tracepoint to track > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > I agree this part. > > > the number of > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > effectiveness. > > I agree nr_taken for knowing shrinking effectiveness but don't > agree nr_scanned. If we want to know LRU isolation effectiveness > with nr_scanned and nr_taken, isolate_lru_pages will do. Yes it will. On the other hand the number is there and there is no additional overhead, maintenance or otherwise, to provide that number. The inactive counterpart does that for quite some time already. So why exactly does that matter? Don't take me wrong but isn't this more on a nit picking side than necessary? Or do I just misunderstand your concenrs? It is not like we are providing a stable user API as the tracepoint is clearly implementation specific and not something to be used for anything other than debugging. > > - nr_rotated pages which tells us that we are hitting referenced > > pages which are deactivated. If this is a large part of the > > reported nr_deactivated pages then the active list is too small > > It might be but not exactly. If your goal is to know LRU size, it can be > done in get_scan_count. I tend to agree LRU size is helpful for > performance analysis because decreased LRU size signals memory shortage > then performance drop. No, I am not really interested in the exact size but rather to allow to find whether we are aging the active list too early... > > > - nr_activated pages which tells us how many pages are keept on the > kept fixed > > > active list - mostly exec pages. A high number can indicate > > file-based exec pages OK, fixed > > > that we might be trashing on executables. > > And welcome to drop nr_unevictable, nr_freed. > > I will be off until next week monday so please understand if my response > is slow. There is no reason to hurry... -- Michal Hocko SUSE Labs -- 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-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 688846B0038 for ; Fri, 30 Dec 2016 12:30:29 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id c85so36510476wmi.6 for ; Fri, 30 Dec 2016 09:30:29 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id ur3si63081083wjb.33.2016.12.30.09.30.28 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 30 Dec 2016 09:30:28 -0800 (PST) Date: Fri, 30 Dec 2016 18:30:24 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230173023.GA4962@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230163742.GK13301@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Fri 30-12-16 17:37:42, Michal Hocko wrote: > On Sat 31-12-16 01:04:56, Minchan Kim wrote: [...] > > > - nr_rotated pages which tells us that we are hitting referenced > > > pages which are deactivated. If this is a large part of the > > > reported nr_deactivated pages then the active list is too small > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > done in get_scan_count. I tend to agree LRU size is helpful for > > performance analysis because decreased LRU size signals memory shortage > > then performance drop. > > No, I am not really interested in the exact size but rather to allow to > find whether we are aging the active list too early... But thinking about that some more, maybe sticking with the nr_rotated terminology is rather confusing and displaying the value as nr_referenced would be more clear. -- Michal Hocko SUSE Labs -- 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-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id E0CCB6B0069 for ; Tue, 3 Jan 2017 00:03:30 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id n189so905744943pga.4 for ; Mon, 02 Jan 2017 21:03:30 -0800 (PST) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id v14si43297975pgo.85.2017.01.02.21.03.29 for ; Mon, 02 Jan 2017 21:03:30 -0800 (PST) Date: Tue, 3 Jan 2017 14:03:28 +0900 From: Minchan Kim Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170103050328.GA15700@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230163742.GK13301@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Hi Michal, On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > [...] > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > things are progressing. We are, however, missing a tracepoint to track > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > I agree this part. > > > > > the number of > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > effectiveness. > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > agree nr_scanned. If we want to know LRU isolation effectiveness > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > Yes it will. On the other hand the number is there and there is no > additional overhead, maintenance or otherwise, to provide that number. You are adding some instructions, how can you imagine it's no overhead? Let's say whether it's measurable. Although it's not big in particular case, it would be measurable if everyone start to say like that "it's trivial so what's the problem adding a few instructions although it was duplicated?" You already said "LRU isolate effectiveness". It should be done in there, isolate_lru_pages and we have been. You need another reasons if you want to add the duplicated work, strongly. > The inactive counterpart does that for quite some time already. So why It couldn't be a reason. If it was duplicated in there, it would be better to fix it rather than adding more duplciated work to match both sides. > exactly does that matter? Don't take me wrong but isn't this more on a > nit picking side than necessary? Or do I just misunderstand your > concenrs? It is not like we are providing a stable user API as the My concern is that I don't see what we can get benefit from those duplicated work. If it doesn't give benefit to us, I don't want to add. I hope you think another reasonable reasons. > tracepoint is clearly implementation specific and not something to be > used for anything other than debugging. My point is we already had things "LRU isolation effectivness". Namely, isolate_lru_pages. > > > > - nr_rotated pages which tells us that we are hitting referenced > > > pages which are deactivated. If this is a large part of the > > > reported nr_deactivated pages then the active list is too small > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > done in get_scan_count. I tend to agree LRU size is helpful for > > performance analysis because decreased LRU size signals memory shortage > > then performance drop. > > No, I am not really interested in the exact size but rather to allow to > find whether we are aging the active list too early... Could you elaborate it more that how we can get active list early aging with nr_rotated? 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-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id BF2826B0069 for ; Tue, 3 Jan 2017 03:21:27 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id c85so46478888wmi.6 for ; Tue, 03 Jan 2017 00:21:27 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id j16si72536057wmd.116.2017.01.03.00.21.26 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 00:21:26 -0800 (PST) Date: Tue, 3 Jan 2017 09:21:22 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170103082122.GA30111@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103050328.GA15700@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Tue 03-01-17 14:03:28, Minchan Kim wrote: > Hi Michal, > > On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > > [...] > > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > > From: Michal Hocko > > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > > things are progressing. We are, however, missing a tracepoint to track > > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > > > I agree this part. > > > > > > > the number of > > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > > effectiveness. > > > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > > agree nr_scanned. If we want to know LRU isolation effectiveness > > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > > > Yes it will. On the other hand the number is there and there is no > > additional overhead, maintenance or otherwise, to provide that number. > > You are adding some instructions, how can you imagine it's no overhead? There should be close to zero overhead when the tracepoint is disabled (we pay only one more argument when the function is called). Is this really worth discussing in this cold path? We are talking about the reclaim here. > Let's say whether it's measurable. Although it's not big in particular case, > it would be measurable if everyone start to say like that "it's trivial so > what's the problem adding a few instructions although it was duplicated?" > > You already said "LRU isolate effectiveness". It should be done in there, > isolate_lru_pages and we have been. You need another reasons if you want to > add the duplicated work, strongly. isolate_lru_pages is certainly there but you have to enable a trace point for that. Sometimes it is quite useful to get a reasonably good picture even without all the vmscan tracepoints enabled because they can generate quite a lot of output. So if the counter is available I see no reason to exclude it, especially when it can provide a useful information. One of the most frustrating debugging experience is when you are missing some part of the information and have to guess which part is that and patch, rebuild the kernel and hope to reproduce it again in the same/similar way. There are two things about this and other tracepoint patches in general I believe. 1) Is the tracepoint useful? and 2) Do we have to go over extra hops to show tracepoint data? I guess we are in an agreement that the answer for 1 is yes. And regarding 2, all the data we are showing are there or trivially retrieved without touching _any_ hot path. Som of it might be duplicated with other tracepoints but that can be helpful because you do not have all the tracepoints enabled all the time. So unless you see this particular thing as a road block I would rather keep it. > > The inactive counterpart does that for quite some time already. So why > > It couldn't be a reason. If it was duplicated in there, it would be > better to fix it rather than adding more duplciated work to match both > sides. I really do not see this as a bad thing. > > exactly does that matter? Don't take me wrong but isn't this more on a > > nit picking side than necessary? Or do I just misunderstand your > > concenrs? It is not like we are providing a stable user API as the > > My concern is that I don't see what we can get benefit from those > duplicated work. If it doesn't give benefit to us, I don't want to add. > I hope you think another reasonable reasons. > > > tracepoint is clearly implementation specific and not something to be > > used for anything other than debugging. > > My point is we already had things "LRU isolation effectivness". Namely, > isolate_lru_pages. > > > > > > > - nr_rotated pages which tells us that we are hitting referenced > > > > pages which are deactivated. If this is a large part of the > > > > reported nr_deactivated pages then the active list is too small > > > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > > done in get_scan_count. I tend to agree LRU size is helpful for > > > performance analysis because decreased LRU size signals memory shortage > > > then performance drop. > > > > No, I am not really interested in the exact size but rather to allow to > > find whether we are aging the active list too early... > > Could you elaborate it more that how we can get active list early aging > with nr_rotated? If you see too many referenced pages on the active list then they have been used since promoted and that is an indication that they might be reclaimed too early. If you are debugging a performance issue and see this happening then it might be a good indication to look at. Thanks -- Michal Hocko SUSE Labs -- 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-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id A490C6B0069 for ; Tue, 3 Jan 2017 12:09:01 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id m203so80185348wma.2 for ; Tue, 03 Jan 2017 09:09:01 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id w62si74244876wme.143.2017.01.03.09.09.00 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 09:09:00 -0800 (PST) Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> From: Vlastimil Babka Message-ID: <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> Date: Tue, 3 Jan 2017 18:08:58 +0100 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko , linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML , Michal Hocko On 12/28/2016 04:30 PM, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + Does this work with external tools such as trace-cmd, i.e. does it export the correct format file? I wouldn't expect it to be that easy to avoid the EM()/EMe() dance :) Also can we make the symbolic names lower_case and without the LRU_ prefix? I think it's more consistent with other mm tracepoints, shorter and nicer. > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > -- 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-wm0-f69.google.com (mail-wm0-f69.google.com [74.125.82.69]) by kanga.kvack.org (Postfix) with ESMTP id 1DE7F6B0069 for ; Tue, 3 Jan 2017 12:21:51 -0500 (EST) Received: by mail-wm0-f69.google.com with SMTP id s63so79854796wms.7 for ; Tue, 03 Jan 2017 09:21:51 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id z80si74293102wmd.57.2017.01.03.09.21.49 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 09:21:50 -0800 (PST) Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> From: Vlastimil Babka Message-ID: Date: Tue, 3 Jan 2017 18:21:48 +0100 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko , linux-mm@kvack.org Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML , Michal Hocko On 12/28/2016 04:30 PM, Michal Hocko wrote: > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > unsigned long nr_taken = 0; > unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; > unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; > + unsigned long skipped = 0, total_skipped = 0; > unsigned long scan, nr_pages; > LIST_HEAD(pages_skipped); > > @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > */ > if (!list_empty(&pages_skipped)) { > int zid; > - unsigned long total_skipped = 0; > > for (zid = 0; zid < MAX_NR_ZONES; zid++) { > if (!nr_skipped[zid]) > continue; > > __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); > - total_skipped += nr_skipped[zid]; > + skipped += nr_skipped[zid]; > } > > /* > @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > * close to unreclaimable. If the LRU list is empty, account > * skipped pages as a full scan. > */ > - scan += list_empty(src) ? total_skipped : total_skipped >> 2; > + total_skipped = list_empty(src) ? skipped : skipped >> 2; Should the tracepoint output reflect this halving heuristic or rather report the raw data? Or is each variant inferrable from the other? > > list_splice(&pages_skipped, src); > } > - *nr_scanned = scan; > + *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, is_file_lru(lru)); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > -- 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-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 02E346B0261 for ; Tue, 3 Jan 2017 15:43:37 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id c85so49244934wmi.6 for ; Tue, 03 Jan 2017 12:43:36 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id k15si74900358wmi.37.2017.01.03.12.43.35 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 12:43:35 -0800 (PST) Date: Tue, 3 Jan 2017 21:43:33 +0100 From: Michal Hocko Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Message-ID: <20170103204331.GB13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> 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: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On Tue 03-01-17 18:21:48, Vlastimil Babka wrote: > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > unsigned long nr_taken = 0; > > unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; > > unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; > > + unsigned long skipped = 0, total_skipped = 0; > > unsigned long scan, nr_pages; > > LIST_HEAD(pages_skipped); > > > > @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > */ > > if (!list_empty(&pages_skipped)) { > > int zid; > > - unsigned long total_skipped = 0; > > > > for (zid = 0; zid < MAX_NR_ZONES; zid++) { > > if (!nr_skipped[zid]) > > continue; > > > > __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); > > - total_skipped += nr_skipped[zid]; > > + skipped += nr_skipped[zid]; > > } > > > > /* > > @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > * close to unreclaimable. If the LRU list is empty, account > > * skipped pages as a full scan. > > */ > > - scan += list_empty(src) ? total_skipped : total_skipped >> 2; > > + total_skipped = list_empty(src) ? skipped : skipped >> 2; > > Should the tracepoint output reflect this halving heuristic or rather report > the raw data? Or is each variant inferrable from the other? I would rather see the raw data because you can always go and check the _current_ implementation and calculate the heuristic. -- Michal Hocko SUSE Labs -- 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-wj0-f197.google.com (mail-wj0-f197.google.com [209.85.210.197]) by kanga.kvack.org (Postfix) with ESMTP id A443B6B0261 for ; Tue, 3 Jan 2017 15:47:49 -0500 (EST) Received: by mail-wj0-f197.google.com with SMTP id iq1so51552898wjb.1 for ; Tue, 03 Jan 2017 12:47:49 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 203si74841878wms.92.2017.01.03.12.47.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 12:47:48 -0800 (PST) Date: Tue, 3 Jan 2017 21:47:45 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103204745.GC13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > the tracepoint to show symbolic names of the lru rather. > > > > Signed-off-by: Michal Hocko > > --- > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > mm/vmscan.c | 2 +- > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 6af4dae46db2..cc0b4c456c78 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -36,6 +36,14 @@ > > (RECLAIM_WB_ASYNC) \ > > ) > > > > +#define show_lru_name(lru) \ > > + __print_symbolic(lru, \ > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > + > > Does this work with external tools such as trace-cmd, i.e. does it export > the correct format file? How do I find out? > I wouldn't expect it to be that easy to avoid the EM()/EMe() dance :) Well, I will not pretend I understand the EM dances... > Also can we make the symbolic names lower_case and without the LRU_ prefix? > I think it's more consistent with other mm tracepoints, shorter and nicer. OK, will make it lowercase without the LRU_ prefix. -- Michal Hocko SUSE Labs -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id B0EB26B0069 for ; Tue, 3 Jan 2017 15:52:48 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id n3so57072559wjy.6 for ; Tue, 03 Jan 2017 12:52:48 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id s10si78625230wjo.159.2017.01.03.12.52.47 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 12:52:47 -0800 (PST) Date: Tue, 3 Jan 2017 21:52:44 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103205244.GD13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103204745.GC13873@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On Tue 03-01-17 21:47:45, Michal Hocko wrote: > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > from is file or anonymous but we do not know which LRU this is. It is > > > useful to know whether the list is file or anonymous as well. Change > > > the tracepoint to show symbolic names of the lru rather. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > > mm/vmscan.c | 2 +- > > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 6af4dae46db2..cc0b4c456c78 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -36,6 +36,14 @@ > > > (RECLAIM_WB_ASYNC) \ > > > ) > > > > > > +#define show_lru_name(lru) \ > > > + __print_symbolic(lru, \ > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > > + > > > > Does this work with external tools such as trace-cmd, i.e. does it export > > the correct format file? > > How do I find out? Well, I've just checked the format file and it says print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) So the tool should be OK as long as it can find values for LRU_* constants. Is this what is the problem? -- Michal Hocko SUSE Labs -- 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-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id A1B0E6B0069 for ; Tue, 3 Jan 2017 16:24:16 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id hb5so112890189wjc.2 for ; Tue, 03 Jan 2017 13:24:16 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id l6si78595715wje.169.2017.01.03.13.24.14 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 13:24:14 -0800 (PST) Date: Tue, 3 Jan 2017 22:24:11 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103212411.GA17822@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103205244.GD13873@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On Tue 03-01-17 21:52:44, Michal Hocko wrote: > On Tue 03-01-17 21:47:45, Michal Hocko wrote: > > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > > > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > > from is file or anonymous but we do not know which LRU this is. It is > > > > useful to know whether the list is file or anonymous as well. Change > > > > the tracepoint to show symbolic names of the lru rather. > > > > > > > > Signed-off-by: Michal Hocko > > > > --- > > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > > > mm/vmscan.c | 2 +- > > > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > > index 6af4dae46db2..cc0b4c456c78 100644 > > > > --- a/include/trace/events/vmscan.h > > > > +++ b/include/trace/events/vmscan.h > > > > @@ -36,6 +36,14 @@ > > > > (RECLAIM_WB_ASYNC) \ > > > > ) > > > > > > > > +#define show_lru_name(lru) \ > > > > + __print_symbolic(lru, \ > > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > > > + > > > > > > Does this work with external tools such as trace-cmd, i.e. does it export > > > the correct format file? > > > > How do I find out? > > Well, I've just checked the format file and it says > print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > So the tool should be OK as long as it can find values for LRU_* > constants. Is this what is the problem? OK, I got it. We need enum->value translation and all the EM stuff to do that, right? I will rework the patch and move the definition to the rest of the EM family... -- Michal Hocko SUSE Labs -- 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-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id 570846B0069 for ; Tue, 3 Jan 2017 16:40:26 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id j10so112805100wjb.3 for ; Tue, 03 Jan 2017 13:40:26 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 13si75083478wmb.71.2017.01.03.13.40.24 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 13:40:24 -0800 (PST) Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> <20170103212411.GA17822@dhcp22.suse.cz> From: Vlastimil Babka Message-ID: Date: Tue, 3 Jan 2017 22:40:23 +0100 MIME-Version: 1.0 In-Reply-To: <20170103212411.GA17822@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On 01/03/2017 10:24 PM, Michal Hocko wrote: > On Tue 03-01-17 21:52:44, Michal Hocko wrote: >> On Tue 03-01-17 21:47:45, Michal Hocko wrote: >> > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: >> > > On 12/28/2016 04:30 PM, Michal Hocko wrote: >> > > > From: Michal Hocko >> > > > >> > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate >> > > > from is file or anonymous but we do not know which LRU this is. It is >> > > > useful to know whether the list is file or anonymous as well. Change >> > > > the tracepoint to show symbolic names of the lru rather. >> > > > >> > > > Signed-off-by: Michal Hocko >> > > > --- >> > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ >> > > > mm/vmscan.c | 2 +- >> > > > 2 files changed, 15 insertions(+), 7 deletions(-) >> > > > >> > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h >> > > > index 6af4dae46db2..cc0b4c456c78 100644 >> > > > --- a/include/trace/events/vmscan.h >> > > > +++ b/include/trace/events/vmscan.h >> > > > @@ -36,6 +36,14 @@ >> > > > (RECLAIM_WB_ASYNC) \ >> > > > ) >> > > > >> > > > +#define show_lru_name(lru) \ >> > > > + __print_symbolic(lru, \ >> > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ >> > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ >> > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ >> > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ >> > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) >> > > > + >> > > >> > > Does this work with external tools such as trace-cmd, i.e. does it export >> > > the correct format file? >> > >> > How do I find out? You did :) Another way to verify is to use trace-cmd tool instead of manual sysfs operations and see if the output looks as expected. The tool gets the raw records from kernel and does the printing in userspace, unlike "cat trace_pipe". >> Well, I've just checked the format file and it says >> print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) >> >> So the tool should be OK as long as it can find values for LRU_* >> constants. Is this what is the problem? Exactly. > OK, I got it. We need enum->value translation and all the EM stuff to do > that, right? Yep. > I will rework the patch and move the definition to the rest of the EM > family... 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-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id AD5056B0069 for ; Tue, 3 Jan 2017 16:48:58 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id u144so81094802wmu.1 for ; Tue, 03 Jan 2017 13:48:58 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id v4si78764018wjr.104.2017.01.03.13.48.57 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 13:48:57 -0800 (PST) Date: Tue, 3 Jan 2017 22:48:54 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103214854.GC18167@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> <20170103212411.GA17822@dhcp22.suse.cz> 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: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On Tue 03-01-17 22:40:23, Vlastimil Babka wrote: > On 01/03/2017 10:24 PM, Michal Hocko wrote: [...] > > > So the tool should be OK as long as it can find values for LRU_* > > > constants. Is this what is the problem? > > Exactly. So this should make it work (it compiles it has to be correct, right?). --- diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h index aa4caa6914a9..6172afa2fd82 100644 --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ EMe(ZONE_MOVABLE,"Movable") +#define LRU_NAMES \ + EM (LRU_INACTIVE_ANON, "inactive_anon") \ + EM (LRU_ACTIVE_ANON, "active_anon") \ + EM (LRU_INACTIVE_FILE, "inactive_file") \ + EM (LRU_ACTIVE_FILE, "active_file") \ + EMe(LRU_UNEVICTABLE, "unevictable") + /* * First define the enums in the above macros to be exported to userspace * via TRACE_DEFINE_ENUM(). @@ -253,6 +260,7 @@ COMPACTION_STATUS COMPACTION_PRIORITY COMPACTION_FEEDBACK ZONE_TYPE +LRU_NAMES /* * Now redefine the EM() and EMe() macros to map the enums to the strings diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 8e7c4c56499a..3c38d9315b43 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -36,14 +36,6 @@ (RECLAIM_WB_ASYNC) \ ) -#define show_lru_name(lru) \ - __print_symbolic(lru, \ - {LRU_INACTIVE_ANON, "inactive_anon"}, \ - {LRU_ACTIVE_ANON, "active_anon"}, \ - {LRU_INACTIVE_FILE, "inactive_file"}, \ - {LRU_ACTIVE_FILE, "active_file"}, \ - {LRU_UNEVICTABLE, "unevictable"}) - TRACE_EVENT(mm_vmscan_kswapd_sleep, TP_PROTO(int nid), @@ -319,7 +311,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - show_lru_name(__entry->lru)) + __print_symbolic(__entry->lru, LRU_NAMES)) ); TRACE_EVENT(mm_vmscan_writepage, -- Michal Hocko SUSE Labs -- 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-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id 679366B0038 for ; Wed, 4 Jan 2017 00:07:25 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id g1so1338743129pgn.3 for ; Tue, 03 Jan 2017 21:07:25 -0800 (PST) Received: from lgeamrelo13.lge.com (LGEAMRELO13.lge.com. [156.147.23.53]) by mx.google.com with ESMTP id j61si71250335plb.116.2017.01.03.21.07.23 for ; Tue, 03 Jan 2017 21:07:24 -0800 (PST) Date: Wed, 4 Jan 2017 14:07:22 +0900 From: Minchan Kim Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170104050722.GA17166@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103082122.GA30111@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote: > On Tue 03-01-17 14:03:28, Minchan Kim wrote: > > Hi Michal, > > > > On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > > > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > > > [...] > > > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > > > From: Michal Hocko > > > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > > > things are progressing. We are, however, missing a tracepoint to track > > > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > > > > > I agree this part. > > > > > > > > > the number of > > > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > > > effectiveness. > > > > > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > > > agree nr_scanned. If we want to know LRU isolation effectiveness > > > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > > > > > Yes it will. On the other hand the number is there and there is no > > > additional overhead, maintenance or otherwise, to provide that number. > > > > You are adding some instructions, how can you imagine it's no overhead? > > There should be close to zero overhead when the tracepoint is disabled > (we pay only one more argument when the function is called). Is this > really worth discussing in this cold path? We are talking about the > reclaim here. I am talking about that why we should add pointless code in there. No matter it's overhead. We are looping infinite. Blindly, it adds overhead although you might think so trivial. > > > Let's say whether it's measurable. Although it's not big in particular case, > > it would be measurable if everyone start to say like that "it's trivial so > > what's the problem adding a few instructions although it was duplicated?" > > > > You already said "LRU isolate effectiveness". It should be done in there, > > isolate_lru_pages and we have been. You need another reasons if you want to > > add the duplicated work, strongly. > > isolate_lru_pages is certainly there but you have to enable a trace > point for that. Sometimes it is quite useful to get a reasonably good > picture even without all the vmscan tracepoints enabled because they > can generate quite a lot of output. So if the counter is available I If someone want to see "isolate effectivenss", he should enable mm_vmscan_lru_isolate which was born in that and has more helpful information. Think it in an opposit way. If some users want to see just active list aging problem and no interested in "LRU isolate effectivness", you are adding meaningless output for him and he has no choice to turn it off with your patch. > see no reason to exclude it, especially when it can provide a useful > information. One of the most frustrating debugging experience is when I said several times. Please think over if everyone begins adding extra parameters in every tracepoints which we could already get it via other tracepoint with "just, it might be useful in a specific context". Could you be happy with that, really? > you are missing some part of the information and have to guess which > part is that and patch, rebuild the kernel and hope to reproduce it > again in the same/similar way. No need to rebuild. Just enable mm_vmscan_lru_isolate. > > There are two things about this and other tracepoint patches in general > I believe. 1) Is the tracepoint useful? and 2) Do we have to go over > extra hops to show tracepoint data? > > I guess we are in an agreement that the answer for 1 is yes. And yeb. > regarding 2, all the data we are showing are there or trivially > retrieved without touching _any_ hot path. Som of it might be duplicated Currently, you rely on just unfortunate modulization to just add unncessary information to the tracepoint. I just removed nr_scanned in your patch and look below. ./scripts/bloat-o-meter vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 0/6 up/down: 0/-147 (-147) function old new delta perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 shrink_active_list 1265 1232 -33 trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 Total: Before=26268743, After=26268596, chg -0.00% Let's furhter it more. We can factor out logics to account isolation of LRU from shrink_[in]active_list which is more clean, I think. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id 266BE6B0038 for ; Wed, 4 Jan 2017 02:28:47 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id hb5so114333059wjc.2 for ; Tue, 03 Jan 2017 23:28:47 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id qa4si80369186wjc.238.2017.01.03.23.28.45 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 23:28:46 -0800 (PST) Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> <20170104050722.GA17166@bbox> From: Vlastimil Babka Message-ID: <9f77c4d2-dddf-8fc6-0982-edf02a58b15f@suse.cz> Date: Wed, 4 Jan 2017 08:28:43 +0100 MIME-Version: 1.0 In-Reply-To: <20170104050722.GA17166@bbox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim , Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML On 01/04/2017 06:07 AM, Minchan Kim wrote: > With this, > ./scripts/bloat-o-meter vmlinux.old vmlinux.new.new > add/remove: 1/1 grow/shrink: 0/9 up/down: 1394/-1636 (-242) > function old new delta > isolate_lru_pages - 1394 +1394 > print_fmt_mm_vmscan_lru_shrink_inactive 359 355 -4 > vermagic 64 58 -6 > perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 > trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 > trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 > print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 > trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 > shrink_inactive_list 1430 1271 -159 > shrink_active_list 1265 1082 -183 > isolate_lru_pages.isra 1170 - -1170 > Total: Before=26268743, After=26268501, chg -0.00% > > We can save 242 bytes. > > If we consider binary size, 424 bytes save. > > #> ls -l vmlinux.old vmlinux.new.new > 194092840 vmlinux.old > 194092416 vmlinux.new.new Which is roughly 0.0002%. Not that I'm against fighting bloat, but let's not forget that it's not the only factor. For example the following part from above: > isolate_lru_pages - 1394 +1394 > isolate_lru_pages.isra 1170 - -1170 shows that your change has prevented a -fipa-src gcc optimisation, which is "interprocedural scalar replacement of aggregates, removal of unused parameters and replacement of parameters passed by reference by parameters passed by value." Well, I'm no gcc expert :) but it might be that the change is not a simple win-win. -- 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-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id 0CB1A6B025E for ; Wed, 4 Jan 2017 02:51:04 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id j10so114278513wjb.3 for ; Tue, 03 Jan 2017 23:51:03 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id u8si76739692wmd.98.2017.01.03.23.51.02 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 23:51:02 -0800 (PST) Date: Wed, 4 Jan 2017 08:50:58 +0100 From: Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170104075058.GA25453@dhcp22.suse.cz> References: <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> <20170104050722.GA17166@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104050722.GA17166@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML On Wed 04-01-17 14:07:22, Minchan Kim wrote: > On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote: [...] > > with other tracepoints but that can be helpful because you do not have > > all the tracepoints enabled all the time. So unless you see this > > particular thing as a road block I would rather keep it. > > I didn't know how long this thread becomes lenghy. To me, it was no worth > to discuss. I did best effot to explain my stand with valid points, I think > and don't want to go infinite loop. If you don't agree still, separate > the patch. One includes only necessary things with removing nr_scanned, which > I am happy to ack it. Based upon it, add one more patch you want adding > nr_scanned with your claim. I will reply that thread with my claim and > let's keep an eye on it that whether maintainer will take it or not. To be honest this is just not worth the effort and rather than discussing further I will just drop the nr_scanned slthough I disagree that your concerns regarding this _particular counter_ are really valid. > If maintainer will take it, it's good indication which will represent > we can add more extra tracepoint easily with "might be helpful with someone > although it's redunant" so do not prevent others who want to do > in the future. no we do not work in a precedence system like that. -- Michal Hocko SUSE Labs -- 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-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id AB3396B0269 for ; Wed, 4 Jan 2017 05:19:58 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id m203so83111384wma.2 for ; Wed, 04 Jan 2017 02:19:58 -0800 (PST) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com. [74.125.82.65]) by mx.google.com with ESMTPS id 65si77183141wmo.84.2017.01.04.02.19.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 02:19:57 -0800 (PST) Received: by mail-wm0-f65.google.com with SMTP id l2so65330601wml.2 for ; Wed, 04 Jan 2017 02:19:57 -0800 (PST) From: Michal Hocko Subject: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Wed, 4 Jan 2017 11:19:39 +0100 Message-Id: <20170104101942.4860-5-mhocko@kernel.org> In-Reply-To: <20170104101942.4860-1-mhocko@kernel.org> References: <20170104101942.4860-1-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , Minchan Kim , Hillf Danton , linux-mm@kvack.org, LKML , Michal Hocko From: Michal Hocko mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is active or inactive, since we are using the same function to isolate pages from both of them and it's hard to distinguish otherwise. Chaneges since v1 - drop LRU_ prefix from names and use lowercase as per Vlastimil - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil Acked-by: Hillf Danton Acked-by: Mel Gorman Signed-off-by: Michal Hocko --- include/trace/events/mmflags.h | 8 ++++++++ include/trace/events/vmscan.h | 12 ++++++------ mm/vmscan.c | 2 +- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h index aa4caa6914a9..6172afa2fd82 100644 --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ EMe(ZONE_MOVABLE,"Movable") +#define LRU_NAMES \ + EM (LRU_INACTIVE_ANON, "inactive_anon") \ + EM (LRU_ACTIVE_ANON, "active_anon") \ + EM (LRU_INACTIVE_FILE, "inactive_file") \ + EM (LRU_ACTIVE_FILE, "active_file") \ + EMe(LRU_UNEVICTABLE, "unevictable") + /* * First define the enums in the above macros to be exported to userspace * via TRACE_DEFINE_ENUM(). @@ -253,6 +260,7 @@ COMPACTION_STATUS COMPACTION_PRIORITY COMPACTION_FEEDBACK ZONE_TYPE +LRU_NAMES /* * Now redefine the EM() and EMe() macros to map the enums to the strings diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 36c999f806bf..7ec59e0432c4 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, - int file), + int lru), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), TP_STRUCT__entry( __field(int, classzone_idx) @@ -289,7 +289,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) - __field(int, file) + __field(int, lru) ), TP_fast_assign( @@ -300,10 +300,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; - __entry->file = file; + __entry->lru = lru; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", __entry->isolate_mode, __entry->classzone_idx, __entry->order, @@ -311,7 +311,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - __entry->file) + __print_symbolic(__entry->lru, LRU_NAMES)) ); TRACE_EVENT(mm_vmscan_writepage, diff --git a/mm/vmscan.c b/mm/vmscan.c index 31c623d5acb4..13758aaed78b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - skipped, nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, lru); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.11.0 -- 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-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id E33AC6B0069 for ; Thu, 5 Jan 2017 01:05:07 -0500 (EST) Received: by mail-pg0-f71.google.com with SMTP id g1so1420919151pgn.3 for ; Wed, 04 Jan 2017 22:05:07 -0800 (PST) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id p62si74706711pfl.255.2017.01.04.22.05.05 for ; Wed, 04 Jan 2017 22:05:06 -0800 (PST) Date: Thu, 5 Jan 2017 15:04:58 +0900 From: Minchan Kim Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105060458.GC24371@bbox> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104101942.4860-5-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML , Michal Hocko On Wed, Jan 04, 2017 at 11:19:39AM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. > > It is useful to know whether the list is active or inactive, since we > are using the same function to isolate pages from both of them and it's > hard to distinguish otherwise. > > Chaneges since v1 > - drop LRU_ prefix from names and use lowercase as per Vlastimil > - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil > > Acked-by: Hillf Danton > Acked-by: Mel Gorman > Signed-off-by: Michal Hocko > --- > include/trace/events/mmflags.h | 8 ++++++++ > include/trace/events/vmscan.h | 12 ++++++------ > mm/vmscan.c | 2 +- > 3 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > index aa4caa6914a9..6172afa2fd82 100644 > --- a/include/trace/events/mmflags.h > +++ b/include/trace/events/mmflags.h > @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ > EMe(ZONE_MOVABLE,"Movable") > > +#define LRU_NAMES \ > + EM (LRU_INACTIVE_ANON, "inactive_anon") \ > + EM (LRU_ACTIVE_ANON, "active_anon") \ > + EM (LRU_INACTIVE_FILE, "inactive_file") \ > + EM (LRU_ACTIVE_FILE, "active_file") \ > + EMe(LRU_UNEVICTABLE, "unevictable") > + > /* > * First define the enums in the above macros to be exported to userspace > * via TRACE_DEFINE_ENUM(). > @@ -253,6 +260,7 @@ COMPACTION_STATUS > COMPACTION_PRIORITY > COMPACTION_FEEDBACK > ZONE_TYPE > +LRU_NAMES > > /* > * Now redefine the EM() and EMe() macros to map the enums to the strings > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 36c999f806bf..7ec59e0432c4 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), It may break trace-vmscan-postprocess.pl. Other than that, Acked-by: 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: from mail-wj0-f199.google.com (mail-wj0-f199.google.com [209.85.210.199]) by kanga.kvack.org (Postfix) with ESMTP id A7ACF6B0260 for ; Thu, 5 Jan 2017 05:16:16 -0500 (EST) Received: by mail-wj0-f199.google.com with SMTP id j10so119822572wjb.3 for ; Thu, 05 Jan 2017 02:16:16 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id jv4si84866386wjb.64.2017.01.05.02.16.14 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 05 Jan 2017 02:16:15 -0800 (PST) Date: Thu, 5 Jan 2017 11:16:13 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105101613.GG21618@dhcp22.suse.cz> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170105060458.GC24371@bbox> Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim , Mel Gorman Cc: Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML On Thu 05-01-17 15:04:58, Minchan Kim wrote: > On Wed, Jan 04, 2017 at 11:19:39AM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. > > > > It is useful to know whether the list is active or inactive, since we > > are using the same function to isolate pages from both of them and it's > > hard to distinguish otherwise. > > > > Chaneges since v1 > > - drop LRU_ prefix from names and use lowercase as per Vlastimil > > - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil > > > > Acked-by: Hillf Danton > > Acked-by: Mel Gorman > > Signed-off-by: Michal Hocko > > > --- > > include/trace/events/mmflags.h | 8 ++++++++ > > include/trace/events/vmscan.h | 12 ++++++------ > > mm/vmscan.c | 2 +- > > 3 files changed, 15 insertions(+), 7 deletions(-) > > > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > > index aa4caa6914a9..6172afa2fd82 100644 > > --- a/include/trace/events/mmflags.h > > +++ b/include/trace/events/mmflags.h > > @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > > IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ > > EMe(ZONE_MOVABLE,"Movable") > > > > +#define LRU_NAMES \ > > + EM (LRU_INACTIVE_ANON, "inactive_anon") \ > > + EM (LRU_ACTIVE_ANON, "active_anon") \ > > + EM (LRU_INACTIVE_FILE, "inactive_file") \ > > + EM (LRU_ACTIVE_FILE, "active_file") \ > > + EMe(LRU_UNEVICTABLE, "unevictable") > > + > > /* > > * First define the enums in the above macros to be exported to userspace > > * via TRACE_DEFINE_ENUM(). > > @@ -253,6 +260,7 @@ COMPACTION_STATUS > > COMPACTION_PRIORITY > > COMPACTION_FEEDBACK > > ZONE_TYPE > > +LRU_NAMES > > > > /* > > * Now redefine the EM() and EMe() macros to map the enums to the strings > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 36c999f806bf..7ec59e0432c4 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > unsigned long nr_skipped, > > unsigned long nr_taken, > > isolate_mode_t isolate_mode, > > - int file), > > + int lru), > > It may break trace-vmscan-postprocess.pl. Other than that, I wasn't aware of the script. And you are right it will break it. The following should fix it. Btw. shrink_inactive_list tracepoint changes will to be synced as well. I do not speak perl much but the following should just work (untested yet). --- diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 8f961ef2b457..ba976805853a 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -112,8 +112,8 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; -my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)'; -my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)'; +my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -205,15 +205,15 @@ $regex_wakeup_kswapd = generate_traceevent_regex( $regex_lru_isolate = generate_traceevent_regex( "vmscan/mm_vmscan_lru_isolate", $regex_lru_isolate_default, - "isolate_mode", "order", - "nr_requested", "nr_scanned", "nr_taken", - "file"); + "isolate_mode", "classzone_idx", "order", + "nr_requested", "nr_scanned", "nr_skipped", "nr_taken", + "lru"); $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, - "nid", "zid", - "nr_scanned", "nr_reclaimed", "priority", - "flags"); + "nid", "nr_scanned", "nr_reclaimed", "nr_dirty", "nr_writeback", + "nr_congested", "nr_immediate", "nr_activate", "nr_ref_keep", + "nr_unmap_fail", "priority", "flags"); $regex_lru_shrink_active = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_active", $regex_lru_shrink_active_default, @@ -381,8 +381,8 @@ sub process_events { next; } my $isolate_mode = $1; - my $nr_scanned = $4; - my $file = $6; + my $nr_scanned = $5; + my $file = $8; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -391,7 +391,7 @@ sub process_events { # isolate_both == 3 if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; - if ($file == 1) { + if ($file =~ /_file/) { $perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned; } else { $perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned; @@ -406,8 +406,8 @@ sub process_events { next; } - my $nr_reclaimed = $4; - my $flags = $6; + my $nr_reclaimed = $3; + my $flags = $12; my $file = 0; if ($flags =~ /RECLAIM_WB_FILE/) { $file = 1; > Acked-by: Minchan Kim Thanks -- Michal Hocko SUSE Labs -- 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-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 7B01E6B0261 for ; Thu, 5 Jan 2017 09:56:27 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id m203so89087795wma.2 for ; Thu, 05 Jan 2017 06:56:27 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 199si82085455wmi.91.2017.01.05.06.56.26 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 05 Jan 2017 06:56:26 -0800 (PST) Date: Thu, 5 Jan 2017 14:56:23 +0000 From: Mel Gorman Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105145623.h7jbgke2ij5opsvz@suse.de> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> <20170105101613.GG21618@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170105101613.GG21618@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Minchan Kim , Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML On Thu, Jan 05, 2017 at 11:16:13AM +0100, Michal Hocko wrote: > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 36c999f806bf..7ec59e0432c4 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > > unsigned long nr_skipped, > > > unsigned long nr_taken, > > > isolate_mode_t isolate_mode, > > > - int file), > > > + int lru), > > > > It may break trace-vmscan-postprocess.pl. Other than that, > > I wasn't aware of the script. And you are right it will break it. The > following should fix it. Btw. shrink_inactive_list tracepoint changes > will to be synced as well. I do not speak perl much but the following > should just work (untested yet). It's also optional to remove them. When those were first merged, it was done to illustrate how multiple tracepoints can be used to aggregate tracepoint information. They are better ways of gathering the same class of information. They are of historical interest but not as fully supported scripts that can never break. -- Mel Gorman SUSE Labs -- 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-wj0-f200.google.com (mail-wj0-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id C541E6B0253 for ; Thu, 5 Jan 2017 10:17:40 -0500 (EST) Received: by mail-wj0-f200.google.com with SMTP id qs7so67455323wjc.4 for ; Thu, 05 Jan 2017 07:17:40 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id bl4si45072504wjb.200.2017.01.05.07.17.39 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 05 Jan 2017 07:17:39 -0800 (PST) Date: Thu, 5 Jan 2017 16:17:37 +0100 From: Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105151737.GU21618@dhcp22.suse.cz> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> <20170105101613.GG21618@dhcp22.suse.cz> <20170105145623.h7jbgke2ij5opsvz@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170105145623.h7jbgke2ij5opsvz@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Minchan Kim , Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML On Thu 05-01-17 14:56:23, Mel Gorman wrote: > On Thu, Jan 05, 2017 at 11:16:13AM +0100, Michal Hocko wrote: > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > > index 36c999f806bf..7ec59e0432c4 100644 > > > > --- a/include/trace/events/vmscan.h > > > > +++ b/include/trace/events/vmscan.h > > > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > > > unsigned long nr_skipped, > > > > unsigned long nr_taken, > > > > isolate_mode_t isolate_mode, > > > > - int file), > > > > + int lru), > > > > > > It may break trace-vmscan-postprocess.pl. Other than that, > > > > I wasn't aware of the script. And you are right it will break it. The > > following should fix it. Btw. shrink_inactive_list tracepoint changes > > will to be synced as well. I do not speak perl much but the following > > should just work (untested yet). > > It's also optional to remove them. When those were first merged, it was > done to illustrate how multiple tracepoints can be used to aggregate > tracepoint information. They are better ways of gathering the same class > of information. They are of historical interest but not as fully supported > scripts that can never break. Yeah, that was my understanding and why I didn't consider it a priority. But it seemed like an easy thing to fix even with my anti-perl mindset. Here is the full patch (untested) --- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751362AbcL1Pal (ORCPT ); Wed, 28 Dec 2016 10:30:41 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:33945 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956AbcL1Pak (ORCPT ); Wed, 28 Dec 2016 10:30:40 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Date: Wed, 28 Dec 2016 16:30:25 +0100 Message-Id: <20161228153032.10821-1-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, while debugging [1] I've realized that there is some room for improvements in the tracepoints set we offer currently. I had hard times to make any conclusion from the existing ones. The resulting problem turned out to be active list aging [2] and we are missing at least two tracepoints to debug such a problem. Some existing tracepoints could export more information to see _why_ the reclaim progress cannot be made not only _how much_ we could reclaim. The later could be seen quite reasonably from the vmstat counters already. It can be argued that we are showing too many implementation details in those tracepoints but I consider them way too lowlevel already to be usable by any kernel independent userspace. I would be _really_ surprised if anything but debugging tools have used them. Any feedback is highly appreciated. [1] http://lkml.kernel.org/r/20161215225702.GA27944@boerne.fritz.box [2] http://lkml.kernel.org/r/20161223105157.GB23109@dhcp22.suse.cz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751683AbcL1Pao (ORCPT ); Wed, 28 Dec 2016 10:30:44 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:35244 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751059AbcL1Pal (ORCPT ); Wed, 28 Dec 2016 10:30:41 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 1/7] mm, vmscan: remove unused mm_vmscan_memcg_isolate Date: Wed, 28 Dec 2016 16:30:26 +0100 Message-Id: <20161228153032.10821-2-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko the trace point is not used since 925b7673cce3 ("mm: make per-memcg LRU lists exclusive") so it can be removed. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index c88fd0934e7e..39bad8921ca1 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -269,8 +269,7 @@ TRACE_EVENT(mm_shrink_slab_end, __entry->retval) ); -DECLARE_EVENT_CLASS(mm_vmscan_lru_isolate_template, - +TRACE_EVENT(mm_vmscan_lru_isolate, TP_PROTO(int classzone_idx, int order, unsigned long nr_requested, @@ -311,34 +310,6 @@ DECLARE_EVENT_CLASS(mm_vmscan_lru_isolate_template, __entry->file) ); -DEFINE_EVENT(mm_vmscan_lru_isolate_template, mm_vmscan_lru_isolate, - - TP_PROTO(int classzone_idx, - int order, - unsigned long nr_requested, - unsigned long nr_scanned, - unsigned long nr_taken, - isolate_mode_t isolate_mode, - int file), - - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file) - -); - -DEFINE_EVENT(mm_vmscan_lru_isolate_template, mm_vmscan_memcg_isolate, - - TP_PROTO(int classzone_idx, - int order, - unsigned long nr_requested, - unsigned long nr_scanned, - unsigned long nr_taken, - isolate_mode_t isolate_mode, - int file), - - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file) - -); - TRACE_EVENT(mm_vmscan_writepage, TP_PROTO(struct page *page), -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751825AbcL1Pat (ORCPT ); Wed, 28 Dec 2016 10:30:49 -0500 Received: from mail-wj0-f194.google.com ([209.85.210.194]:36189 "EHLO mail-wj0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbcL1Par (ORCPT ); Wed, 28 Dec 2016 10:30:47 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint Date: Wed, 28 Dec 2016 16:30:31 +0100 Message-Id: <20161228153032.10821-7-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko mm_vmscan_lru_shrink_inactive will currently report the number of scanned and reclaimed pages. This doesn't give us an idea how the reclaim went except for the overall effectiveness though. Export and show other counters which will tell us why we couldn't reclaim some pages. - nr_dirty, nr_writeback, nr_congested and nr_immediate tells us how many pages are blocked due to IO - nr_activate tells us how many pages were moved to the active list - nr_ref_keep reports how many pages are kept on the LRU due to references (mostly for the file pages which are about to go for another round through the inactive list) - nr_unmap_fail - how many pages failed to unmap All these are rather low level so they might change in future but the tracepoint is already implementation specific so no tools should be depending on its stability. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 29 ++++++++++++++++++++++++++--- mm/vmscan.c | 14 ++++++++++++++ 2 files changed, 40 insertions(+), 3 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index cc0b4c456c78..d27606f27af7 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -348,14 +348,27 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_reclaimed, + unsigned long nr_dirty, unsigned long nr_writeback, + unsigned long nr_congested, unsigned long nr_immediate, + unsigned long nr_activate, unsigned long nr_ref_keep, + unsigned long nr_unmap_fail, int priority, int file), - TP_ARGS(nid, nr_scanned, nr_reclaimed, priority, file), + TP_ARGS(nid, nr_scanned, nr_reclaimed, nr_dirty, nr_writeback, + nr_congested, nr_immediate, nr_activate, nr_ref_keep, + nr_unmap_fail, priority, file), TP_STRUCT__entry( __field(int, nid) __field(unsigned long, nr_scanned) __field(unsigned long, nr_reclaimed) + __field(unsigned long, nr_dirty) + __field(unsigned long, nr_writeback) + __field(unsigned long, nr_congested) + __field(unsigned long, nr_immediate) + __field(unsigned long, nr_activate) + __field(unsigned long, nr_ref_keep) + __field(unsigned long, nr_unmap_fail) __field(int, priority) __field(int, reclaim_flags) ), @@ -364,14 +377,24 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, __entry->nid = nid; __entry->nr_scanned = nr_scanned; __entry->nr_reclaimed = nr_reclaimed; + __entry->nr_dirty = nr_dirty; + __entry->nr_writeback = nr_writeback; + __entry->nr_congested = nr_congested; + __entry->nr_immediate = nr_immediate; + __entry->nr_activate = nr_activate; + __entry->nr_ref_keep = nr_ref_keep; + __entry->nr_unmap_fail = nr_unmap_fail; __entry->priority = priority; __entry->reclaim_flags = trace_shrink_flags(file); ), - TP_printk("nid=%d nr_scanned=%ld nr_reclaimed=%ld priority=%d flags=%s", + TP_printk("nid=%d nr_scanned=%ld nr_reclaimed=%ld nr_dirty=%ld nr_writeback=%ld nr_congested=%ld nr_immediate=%ld nr_activate=%ld nr_ref_keep=%ld nr_unmap_fail=%ld priority=%d flags=%s", __entry->nid, __entry->nr_scanned, __entry->nr_reclaimed, - __entry->priority, + __entry->nr_dirty, __entry->nr_writeback, + __entry->nr_congested, __entry->nr_immediate, + __entry->nr_activate, __entry->nr_ref_keep, + __entry->nr_unmap_fail, __entry->priority, show_reclaim_flags(__entry->reclaim_flags)) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index f6f2d828968c..a701bdd6334a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -908,6 +908,9 @@ struct reclaim_stat { unsigned nr_congested; unsigned nr_writeback; unsigned nr_immediate; + unsigned nr_activate; + unsigned nr_ref_keep; + unsigned nr_unmap_fail; }; /* @@ -929,6 +932,8 @@ static unsigned long shrink_page_list(struct list_head *page_list, unsigned nr_reclaimed = 0; unsigned nr_writeback = 0; unsigned nr_immediate = 0; + unsigned nr_ref_keep = 0; + unsigned nr_unmap_fail = 0; cond_resched(); @@ -1067,6 +1072,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, case PAGEREF_ACTIVATE: goto activate_locked; case PAGEREF_KEEP: + nr_ref_keep++; goto keep_locked; case PAGEREF_RECLAIM: case PAGEREF_RECLAIM_CLEAN: @@ -1104,6 +1110,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, (ttu_flags | TTU_BATCH_FLUSH | TTU_LZFREE) : (ttu_flags | TTU_BATCH_FLUSH))) { case SWAP_FAIL: + nr_unmap_fail++; goto activate_locked; case SWAP_AGAIN: goto keep_locked; @@ -1276,6 +1283,9 @@ static unsigned long shrink_page_list(struct list_head *page_list, stat->nr_unqueued_dirty = nr_unqueued_dirty; stat->nr_writeback = nr_writeback; stat->nr_immediate = nr_immediate; + stat->nr_activate = pgactivate; + stat->nr_ref_keep = nr_ref_keep; + stat->nr_unmap_fail = nr_unmap_fail; } return nr_reclaimed; } @@ -1825,6 +1835,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id, nr_scanned, nr_reclaimed, + stat.nr_dirty, stat.nr_writeback, + stat.nr_congested, stat.nr_immediate, + stat.nr_activate, stat.nr_ref_keep, + stat.nr_unmap_fail, sc->priority, file); return nr_reclaimed; } -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751789AbcL1Paq (ORCPT ); Wed, 28 Dec 2016 10:30:46 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36262 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbcL1Pao (ORCPT ); Wed, 28 Dec 2016 10:30:44 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Date: Wed, 28 Dec 2016 16:30:28 +0100 Message-Id: <20161228153032.10821-4-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko mm_vmscan_lru_isolate shows the number of requested, scanned and taken pages. This is mostly OK but on 32b systems the number of scanned pages is quite misleading because it includes both the scanned and skipped pages. Moreover the skipped part is scaled based on the number of taken pages. Let's report the exact numbers without any additional logic and add the number of skipped pages. This should make the reported data much more easier to interpret. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 8 ++++++-- mm/vmscan.c | 10 +++++----- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index d34cc0ced2be..6af4dae46db2 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -274,17 +274,19 @@ TRACE_EVENT(mm_vmscan_lru_isolate, int order, unsigned long nr_requested, unsigned long nr_scanned, + unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, int file), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), TP_STRUCT__entry( __field(int, classzone_idx) __field(int, order) __field(unsigned long, nr_requested) __field(unsigned long, nr_scanned) + __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) __field(int, file) @@ -295,17 +297,19 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->order = order; __entry->nr_requested = nr_requested; __entry->nr_scanned = nr_scanned; + __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; __entry->file = file; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", __entry->isolate_mode, __entry->classzone_idx, __entry->order, __entry->nr_requested, __entry->nr_scanned, + __entry->nr_skipped, __entry->nr_taken, __entry->file) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index 2302a1a58c6e..4f7c0d66d629 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, unsigned long nr_taken = 0; unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; + unsigned long skipped = 0, total_skipped = 0; unsigned long scan, nr_pages; LIST_HEAD(pages_skipped); @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, */ if (!list_empty(&pages_skipped)) { int zid; - unsigned long total_skipped = 0; for (zid = 0; zid < MAX_NR_ZONES; zid++) { if (!nr_skipped[zid]) continue; __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); - total_skipped += nr_skipped[zid]; + skipped += nr_skipped[zid]; } /* @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, * close to unreclaimable. If the LRU list is empty, account * skipped pages as a full scan. */ - scan += list_empty(src) ? total_skipped : total_skipped >> 2; + total_skipped = list_empty(src) ? skipped : skipped >> 2; list_splice(&pages_skipped, src); } - *nr_scanned = scan; + *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, is_file_lru(lru)); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbcL1PbP (ORCPT ); Wed, 28 Dec 2016 10:31:15 -0500 Received: from mail-wj0-f195.google.com ([209.85.210.195]:33715 "EHLO mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbcL1Pas (ORCPT ); Wed, 28 Dec 2016 10:30:48 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 7/7] mm, vmscan: add mm_vmscan_inactive_list_is_low tracepoint Date: Wed, 28 Dec 2016 16:30:32 +0100 Message-Id: <20161228153032.10821-8-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko Currently we have tracepoints for both active and inactive LRU lists reclaim but we do not have any which would tell us why we we decided to age the active list. Without that it is quite hard to diagnose active/inactive lists balancing. Add mm_vmscan_inactive_list_is_low tracepoint to tell us this information. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 40 ++++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 23 ++++++++++++++--------- 2 files changed, 54 insertions(+), 9 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index d27606f27af7..02c038c570a9 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -15,6 +15,7 @@ #define RECLAIM_WB_MIXED 0x0010u #define RECLAIM_WB_SYNC 0x0004u /* Unused, all reclaim async */ #define RECLAIM_WB_ASYNC 0x0008u +#define RECLAIM_WB_LRU (RECLAIM_WB_ANON|RECLAIM_WB_FILE) #define show_reclaim_flags(flags) \ (flags) ? __print_flags(flags, "|", \ @@ -436,6 +437,45 @@ TRACE_EVENT(mm_vmscan_lru_shrink_active, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_vmscan_inactive_list_is_low, + + TP_PROTO(int nid, int reclaim_idx, + unsigned long total_inactive, unsigned long inactive, + unsigned long total_active, unsigned long active, + unsigned long ratio, int file), + + TP_ARGS(nid, reclaim_idx, total_inactive, inactive, total_active, active, ratio, file), + + TP_STRUCT__entry( + __field(int, nid) + __field(int, reclaim_idx) + __field(unsigned long, total_inactive) + __field(unsigned long, inactive) + __field(unsigned long, total_active) + __field(unsigned long, active) + __field(unsigned long, ratio) + __field(int, reclaim_flags) + ), + + TP_fast_assign( + __entry->nid = nid; + __entry->reclaim_idx = reclaim_idx; + __entry->total_inactive = total_inactive; + __entry->inactive = inactive; + __entry->total_active = total_active; + __entry->active = active; + __entry->ratio = ratio; + __entry->reclaim_flags = trace_shrink_flags(file) & RECLAIM_WB_LRU; + ), + + TP_printk("nid=%d reclaim_idx=%d total_inactive=%ld inactive=%ld total_active=%ld active=%ld ratio=%ld flags=%s", + __entry->nid, + __entry->reclaim_idx, + __entry->total_inactive, __entry->inactive, + __entry->total_active, __entry->active, + __entry->ratio, + show_reclaim_flags(__entry->reclaim_flags)) +); #endif /* _TRACE_VMSCAN_H */ /* This part must be outside protection */ diff --git a/mm/vmscan.c b/mm/vmscan.c index a701bdd6334a..8021401213e0 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2041,11 +2041,11 @@ static void shrink_active_list(unsigned long nr_to_scan, * 10TB 320 32GB */ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, - struct scan_control *sc) + struct scan_control *sc, bool trace) { unsigned long inactive_ratio; - unsigned long inactive; - unsigned long active; + unsigned long total_inactive, inactive; + unsigned long total_active, active; unsigned long gb; struct pglist_data *pgdat = lruvec_pgdat(lruvec); int zid; @@ -2057,8 +2057,8 @@ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, if (!file && !total_swap_pages) return false; - inactive = lruvec_lru_size(lruvec, file * LRU_FILE); - active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE); + total_inactive = inactive = lruvec_lru_size(lruvec, file * LRU_FILE); + total_active = active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE); /* * For zone-constrained allocations, it is necessary to check if @@ -2087,6 +2087,11 @@ static bool inactive_list_is_low(struct lruvec *lruvec, bool file, else inactive_ratio = 1; + if (trace) + trace_mm_vmscan_inactive_list_is_low(pgdat->node_id, + sc->reclaim_idx, + total_inactive, inactive, + total_active, active, inactive_ratio, file); return inactive * inactive_ratio < active; } @@ -2094,7 +2099,7 @@ static unsigned long shrink_list(enum lru_list lru, unsigned long nr_to_scan, struct lruvec *lruvec, struct scan_control *sc) { if (is_active_lru(lru)) { - if (inactive_list_is_low(lruvec, is_file_lru(lru), sc)) + if (inactive_list_is_low(lruvec, is_file_lru(lru), sc, true)) shrink_active_list(nr_to_scan, lruvec, sc, lru); return 0; } @@ -2225,7 +2230,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, * lruvec even if it has plenty of old anonymous pages unless the * system is under heavy pressure. */ - if (!inactive_list_is_low(lruvec, true, sc) && + if (!inactive_list_is_low(lruvec, true, sc, false) && lruvec_lru_size(lruvec, LRU_INACTIVE_FILE) >> sc->priority) { scan_balance = SCAN_FILE; goto out; @@ -2450,7 +2455,7 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc * Even if we did not try to evict anon pages at all, we want to * rebalance the anon lru active/inactive ratio. */ - if (inactive_list_is_low(lruvec, false, sc)) + if (inactive_list_is_low(lruvec, false, sc, true)) shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); } @@ -3100,7 +3105,7 @@ static void age_active_anon(struct pglist_data *pgdat, do { struct lruvec *lruvec = mem_cgroup_lruvec(pgdat, memcg); - if (inactive_list_is_low(lruvec, false, sc)) + if (inactive_list_is_low(lruvec, false, sc, true)) shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbcL1Pb2 (ORCPT ); Wed, 28 Dec 2016 10:31:28 -0500 Received: from mail-wj0-f195.google.com ([209.85.210.195]:33702 "EHLO mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751691AbcL1Pap (ORCPT ); Wed, 28 Dec 2016 10:30:45 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 5/7] mm, vmscan: extract shrink_page_list reclaim counters into a struct Date: Wed, 28 Dec 2016 16:30:30 +0100 Message-Id: <20161228153032.10821-6-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko shrink_page_list returns quite some counters back to its caller. Extract the existing 5 into struct reclaim_stat because this makes the code easier to follow and also allows further counters to be returned. While we are at it, make all of them unsigned rather than unsigned long as we do not really need full 64b for them (we never scan more than SWAP_CLUSTER_MAX pages at once). This should reduce some stack space. This patch shouldn't introduce any functional change. Signed-off-by: Michal Hocko --- mm/vmscan.c | 61 ++++++++++++++++++++++++++++++------------------------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 3f0774f30a42..f6f2d828968c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -902,6 +902,14 @@ static void page_check_dirty_writeback(struct page *page, mapping->a_ops->is_dirty_writeback(page, dirty, writeback); } +struct reclaim_stat { + unsigned nr_dirty; + unsigned nr_unqueued_dirty; + unsigned nr_congested; + unsigned nr_writeback; + unsigned nr_immediate; +}; + /* * shrink_page_list() returns the number of reclaimed pages */ @@ -909,22 +917,18 @@ static unsigned long shrink_page_list(struct list_head *page_list, struct pglist_data *pgdat, struct scan_control *sc, enum ttu_flags ttu_flags, - unsigned long *ret_nr_dirty, - unsigned long *ret_nr_unqueued_dirty, - unsigned long *ret_nr_congested, - unsigned long *ret_nr_writeback, - unsigned long *ret_nr_immediate, + struct reclaim_stat *stat, bool force_reclaim) { LIST_HEAD(ret_pages); LIST_HEAD(free_pages); int pgactivate = 0; - unsigned long nr_unqueued_dirty = 0; - unsigned long nr_dirty = 0; - unsigned long nr_congested = 0; - unsigned long nr_reclaimed = 0; - unsigned long nr_writeback = 0; - unsigned long nr_immediate = 0; + unsigned nr_unqueued_dirty = 0; + unsigned nr_dirty = 0; + unsigned nr_congested = 0; + unsigned nr_reclaimed = 0; + unsigned nr_writeback = 0; + unsigned nr_immediate = 0; cond_resched(); @@ -1266,11 +1270,13 @@ static unsigned long shrink_page_list(struct list_head *page_list, list_splice(&ret_pages, page_list); count_vm_events(PGACTIVATE, pgactivate); - *ret_nr_dirty += nr_dirty; - *ret_nr_congested += nr_congested; - *ret_nr_unqueued_dirty += nr_unqueued_dirty; - *ret_nr_writeback += nr_writeback; - *ret_nr_immediate += nr_immediate; + if (stat) { + stat->nr_dirty = nr_dirty; + stat->nr_congested = nr_congested; + stat->nr_unqueued_dirty = nr_unqueued_dirty; + stat->nr_writeback = nr_writeback; + stat->nr_immediate = nr_immediate; + } return nr_reclaimed; } @@ -1282,7 +1288,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, .priority = DEF_PRIORITY, .may_unmap = 1, }; - unsigned long ret, dummy1, dummy2, dummy3, dummy4, dummy5; + unsigned long ret; struct page *page, *next; LIST_HEAD(clean_pages); @@ -1295,8 +1301,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, } ret = shrink_page_list(&clean_pages, zone->zone_pgdat, &sc, - TTU_UNMAP|TTU_IGNORE_ACCESS, - &dummy1, &dummy2, &dummy3, &dummy4, &dummy5, true); + TTU_UNMAP|TTU_IGNORE_ACCESS, NULL, true); list_splice(&clean_pages, page_list); mod_node_page_state(zone->zone_pgdat, NR_ISOLATED_FILE, -ret); return ret; @@ -1696,11 +1701,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, unsigned long nr_scanned; unsigned long nr_reclaimed = 0; unsigned long nr_taken; - unsigned long nr_dirty = 0; - unsigned long nr_congested = 0; - unsigned long nr_unqueued_dirty = 0; - unsigned long nr_writeback = 0; - unsigned long nr_immediate = 0; + struct reclaim_stat stat = {}; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); @@ -1745,9 +1746,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, return 0; nr_reclaimed = shrink_page_list(&page_list, pgdat, sc, TTU_UNMAP, - &nr_dirty, &nr_unqueued_dirty, &nr_congested, - &nr_writeback, &nr_immediate, - false); + &stat, false); spin_lock_irq(&pgdat->lru_lock); @@ -1781,7 +1780,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * of pages under pages flagged for immediate reclaim and stall if any * are encountered in the nr_immediate check below. */ - if (nr_writeback && nr_writeback == nr_taken) + if (stat.nr_writeback && stat.nr_writeback == nr_taken) set_bit(PGDAT_WRITEBACK, &pgdat->flags); /* @@ -1793,7 +1792,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * Tag a zone as congested if all the dirty pages scanned were * backed by a congested BDI and wait_iff_congested will stall. */ - if (nr_dirty && nr_dirty == nr_congested) + if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested) set_bit(PGDAT_CONGESTED, &pgdat->flags); /* @@ -1802,7 +1801,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * the pgdat PGDAT_DIRTY and kswapd will start writing pages from * reclaim context. */ - if (nr_unqueued_dirty == nr_taken) + if (stat.nr_unqueued_dirty == nr_taken) set_bit(PGDAT_DIRTY, &pgdat->flags); /* @@ -1811,7 +1810,7 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * that pages are cycling through the LRU faster than * they are written so also forcibly stall. */ - if (nr_immediate && current_may_throttle()) + if (stat.nr_immediate && current_may_throttle()) congestion_wait(BLK_RW_ASYNC, HZ/10); } -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751912AbcL1Pbr (ORCPT ); Wed, 28 Dec 2016 10:31:47 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:36180 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751059AbcL1Pao (ORCPT ); Wed, 28 Dec 2016 10:30:44 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Wed, 28 Dec 2016 16:30:29 +0100 Message-Id: <20161228153032.10821-5-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is file or anonymous as well. Change the tracepoint to show symbolic names of the lru rather. Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 20 ++++++++++++++------ mm/vmscan.c | 2 +- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 6af4dae46db2..cc0b4c456c78 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -36,6 +36,14 @@ (RECLAIM_WB_ASYNC) \ ) +#define show_lru_name(lru) \ + __print_symbolic(lru, \ + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) + TRACE_EVENT(mm_vmscan_kswapd_sleep, TP_PROTO(int nid), @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, - int file), + int lru), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), TP_STRUCT__entry( __field(int, classzone_idx) @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) - __field(int, file) + __field(int, lru) ), TP_fast_assign( @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; - __entry->file = file; + __entry->lru = lru; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", __entry->isolate_mode, __entry->classzone_idx, __entry->order, @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - __entry->file) + show_lru_name(__entry->lru)) ); TRACE_EVENT(mm_vmscan_writepage, diff --git a/mm/vmscan.c b/mm/vmscan.c index 4f7c0d66d629..3f0774f30a42 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - skipped, nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, lru); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751943AbcL1PcC (ORCPT ); Wed, 28 Dec 2016 10:32:02 -0500 Received: from mail-wj0-f195.google.com ([209.85.210.195]:35248 "EHLO mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751052AbcL1Pan (ORCPT ); Wed, 28 Dec 2016 10:30:43 -0500 From: Michal Hocko To: Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Wed, 28 Dec 2016 16:30:27 +0100 Message-Id: <20161228153032.10821-3-mhocko@kernel.org> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> References: <20161228153032.10821-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko Our reclaim process has several tracepoints to tell us more about how things are progressing. We are, however, missing a tracepoint to track active list aging. Introduce mm_vmscan_lru_shrink_active which reports the number of scanned, rotated, deactivated and freed pages from the particular node's active list. Signed-off-by: Michal Hocko --- include/linux/gfp.h | 2 +- include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 6 +++++- mm/vmscan.c | 22 +++++++++++++++++----- 4 files changed, 61 insertions(+), 7 deletions(-) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 4175dca4ac39..61aa9b49e86d 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); extern void __free_pages(struct page *page, unsigned int order); extern void free_pages(unsigned long addr, unsigned int order); extern void free_hot_cold_page(struct page *page, bool cold); -extern void free_hot_cold_page_list(struct list_head *list, bool cold); +extern int free_hot_cold_page_list(struct list_head *list, bool cold); struct page_frag_cache; extern void __page_frag_drain(struct page *page, unsigned int order, diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 39bad8921ca1..d34cc0ced2be 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_vmscan_lru_shrink_active, + + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, + unsigned long nr_unevictable, unsigned long nr_deactivated, + unsigned long nr_rotated, int priority, int file), + + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), + + TP_STRUCT__entry( + __field(int, nid) + __field(unsigned long, nr_scanned) + __field(unsigned long, nr_freed) + __field(unsigned long, nr_unevictable) + __field(unsigned long, nr_deactivated) + __field(unsigned long, nr_rotated) + __field(int, priority) + __field(int, reclaim_flags) + ), + + TP_fast_assign( + __entry->nid = nid; + __entry->nr_scanned = nr_scanned; + __entry->nr_freed = nr_freed; + __entry->nr_unevictable = nr_unevictable; + __entry->nr_deactivated = nr_deactivated; + __entry->nr_rotated = nr_rotated; + __entry->priority = priority; + __entry->reclaim_flags = trace_shrink_flags(file); + ), + + TP_printk("nid=%d nr_scanned=%ld nr_freed=%ld nr_unevictable=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", + __entry->nid, + __entry->nr_scanned, __entry->nr_freed, __entry->nr_unevictable, + __entry->nr_deactivated, __entry->nr_rotated, + __entry->priority, + show_reclaim_flags(__entry->reclaim_flags)) +); + #endif /* _TRACE_VMSCAN_H */ /* This part must be outside protection */ diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1c24112308d6..77d204660857 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2487,14 +2487,18 @@ void free_hot_cold_page(struct page *page, bool cold) /* * Free a list of 0-order pages */ -void free_hot_cold_page_list(struct list_head *list, bool cold) +int free_hot_cold_page_list(struct list_head *list, bool cold) { struct page *page, *next; + int ret = 0; list_for_each_entry_safe(page, next, list, lru) { trace_mm_page_free_batched(page, cold); free_hot_cold_page(page, cold); + ret++; } + + return ret; } /* diff --git a/mm/vmscan.c b/mm/vmscan.c index c4abf08861d2..2302a1a58c6e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * * The downside is that we have to touch page->_refcount against each page. * But we had to alter page->flags anyway. + * + * Returns the number of pages moved to the given lru. */ -static void move_active_pages_to_lru(struct lruvec *lruvec, +static int move_active_pages_to_lru(struct lruvec *lruvec, struct list_head *list, struct list_head *pages_to_free, enum lru_list lru) @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, unsigned long pgmoved = 0; struct page *page; int nr_pages; + int nr_moved = 0; while (!list_empty(list)) { page = lru_to_page(list); @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, spin_lock_irq(&pgdat->lru_lock); } else list_add(&page->lru, pages_to_free); + } else { + nr_moved++; } } if (!is_active_lru(lru)) __count_vm_events(PGDEACTIVATE, pgmoved); + + return nr_moved; } static void shrink_active_list(unsigned long nr_to_scan, @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, LIST_HEAD(l_inactive); struct page *page; struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; - unsigned long nr_rotated = 0; + unsigned long nr_rotated = 0, nr_unevictable = 0; + unsigned long nr_freed, nr_deactivate, nr_activate; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); @@ -1935,6 +1943,7 @@ static void shrink_active_list(unsigned long nr_to_scan, if (unlikely(!page_evictable(page))) { putback_lru_page(page); + nr_unevictable++; continue; } @@ -1980,13 +1989,16 @@ static void shrink_active_list(unsigned long nr_to_scan, */ reclaim_stat->recent_rotated[file] += nr_rotated; - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); spin_unlock_irq(&pgdat->lru_lock); mem_cgroup_uncharge_list(&l_hold); - free_hot_cold_page_list(&l_hold, true); + nr_freed = free_hot_cold_page_list(&l_hold, true); + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_freed, + nr_unevictable, nr_deactivate, nr_rotated, + sc->priority, file); } /* -- 2.10.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751557AbcL1Pug (ORCPT ); Wed, 28 Dec 2016 10:50:36 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34006 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956AbcL1Puf (ORCPT ); Wed, 28 Dec 2016 10:50:35 -0500 Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint To: Michal Hocko , linux-mm@kvack.org References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko From: Nikolay Borisov Message-ID: Date: Wed, 28 Dec 2016 17:50:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.12.2016 17:30, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751829AbcL1QAf (ORCPT ); Wed, 28 Dec 2016 11:00:35 -0500 Received: from mx2.suse.de ([195.135.220.15]:36522 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751748AbcL1QAd (ORCPT ); Wed, 28 Dec 2016 11:00:33 -0500 Date: Wed, 28 Dec 2016 17:00:29 +0100 From: Michal Hocko To: Nikolay Borisov Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161228160029.GF11470@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: > > > On 28.12.2016 17:30, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? You are right. I will update the wording to: " mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is active or inactive as well as we use the same function to isolate pages for both of them. Change the tracepoint to show symbolic names of the lru rather. " Does it sound better? Thanks! -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751529AbcL1QkV (ORCPT ); Wed, 28 Dec 2016 11:40:21 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36820 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750976AbcL1QkT (ORCPT ); Wed, 28 Dec 2016 11:40:19 -0500 Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint To: Michal Hocko References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161228160029.GF11470@dhcp22.suse.cz> Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML From: Nikolay Borisov Message-ID: <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> Date: Wed, 28 Dec 2016 18:40:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161228160029.GF11470@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.12.2016 18:00, Michal Hocko wrote: > On Wed 28-12-16 17:50:31, Nikolay Borisov wrote: >> >> >> On 28.12.2016 17:30, Michal Hocko wrote: >>> From: Michal Hocko >>> >>> mm_vmscan_lru_isolate currently prints only whether the LRU we isolate >>> from is file or anonymous but we do not know which LRU this is. It is >>> useful to know whether the list is file or anonymous as well. Change >> >> Maybe you wanted to say whether the list is ACTIVE/INACTIVE ? > > You are right. I will update the wording to: > " > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is active or inactive as well as we > use the same function to isolate pages for both of them. Change > the tracepoint to show symbolic names of the lru rather. > " > > Does it sound better? It's better. Just one more nit about the " as well as we use the same function to isolate pages for both of them" I think this can be reworded better. The way I understand is - it's better to know whether it's active/inactive since we are using the same function to do both, correct? If so then then perhaps the following is a bit more clear: " It is useful to know whether the list is active or inactive, since we are using the same function to isolate pages from both of them and it's hard to distinguish otherwise. " But as I said - it's a minor nit. > > 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 S1752075AbcL1Qt7 (ORCPT ); Wed, 28 Dec 2016 11:49:59 -0500 Received: from mx2.suse.de ([195.135.220.15]:39306 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751807AbcL1Qt4 (ORCPT ); Wed, 28 Dec 2016 11:49:56 -0500 Date: Wed, 28 Dec 2016 17:49:52 +0100 From: Michal Hocko To: Nikolay Borisov Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161228164952.GG11470@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161228160029.GF11470@dhcp22.suse.cz> <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a8baddb-842d-31d0-dede-3fb04ed5d9ae@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 28-12-16 18:40:16, Nikolay Borisov wrote: [...] > " > It is useful to know whether the list is active or inactive, since we > are using the same function to isolate pages from both of them and it's > hard to distinguish otherwise. > " OK, updated. Thanks! -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752079AbcL2FeD (ORCPT ); Thu, 29 Dec 2016 00:34:03 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:35668 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751158AbcL2FeC (ORCPT ); Thu, 29 Dec 2016 00:34:02 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 29 Dec 2016 14:33:59 +0900 From: Minchan Kim To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161229053359.GA1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161228153032.10821-3-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > From: Michal Hocko > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > the number of scanned, rotated, deactivated and freed pages from the > particular node's active list. > > Signed-off-by: Michal Hocko > --- > include/linux/gfp.h | 2 +- > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > mm/page_alloc.c | 6 +++++- > mm/vmscan.c | 22 +++++++++++++++++----- > 4 files changed, 61 insertions(+), 7 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 4175dca4ac39..61aa9b49e86d 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > extern void __free_pages(struct page *page, unsigned int order); > extern void free_pages(unsigned long addr, unsigned int order); > extern void free_hot_cold_page(struct page *page, bool cold); > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > struct page_frag_cache; > extern void __page_frag_drain(struct page *page, unsigned int order, > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 39bad8921ca1..d34cc0ced2be 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > show_reclaim_flags(__entry->reclaim_flags)) > ); > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > + > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > + unsigned long nr_unevictable, unsigned long nr_deactivated, > + unsigned long nr_rotated, int priority, int file), > + > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), I agree it is helpful. And it was when I investigated aging problem of 32bit when node-lru was introduced. However, the question is we really need all those kinds of information? just enough with nr_taken, nr_deactivated, priority, file? Also, look at minor thing below. Thanks. > + > + TP_STRUCT__entry( > + __field(int, nid) > + __field(unsigned long, nr_scanned) > + __field(unsigned long, nr_freed) > + __field(unsigned long, nr_unevictable) > + __field(unsigned long, nr_deactivated) > + __field(unsigned long, nr_rotated) > + __field(int, priority) > + __field(int, reclaim_flags) > + ), > + > + TP_fast_assign( > + __entry->nid = nid; > + __entry->nr_scanned = nr_scanned; > + __entry->nr_freed = nr_freed; > + __entry->nr_unevictable = nr_unevictable; > + __entry->nr_deactivated = nr_deactivated; > + __entry->nr_rotated = nr_rotated; > + __entry->priority = priority; > + __entry->reclaim_flags = trace_shrink_flags(file); > + ), > + > + TP_printk("nid=%d nr_scanned=%ld nr_freed=%ld nr_unevictable=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", > + __entry->nid, > + __entry->nr_scanned, __entry->nr_freed, __entry->nr_unevictable, > + __entry->nr_deactivated, __entry->nr_rotated, > + __entry->priority, > + show_reclaim_flags(__entry->reclaim_flags)) > +); > + > #endif /* _TRACE_VMSCAN_H */ > > /* This part must be outside protection */ > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1c24112308d6..77d204660857 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2487,14 +2487,18 @@ void free_hot_cold_page(struct page *page, bool cold) > /* > * Free a list of 0-order pages > */ > -void free_hot_cold_page_list(struct list_head *list, bool cold) > +int free_hot_cold_page_list(struct list_head *list, bool cold) > { > struct page *page, *next; > + int ret = 0; > > list_for_each_entry_safe(page, next, list, lru) { > trace_mm_page_free_batched(page, cold); > free_hot_cold_page(page, cold); > + ret++; > } > + > + return ret; > } > > /* > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c4abf08861d2..2302a1a58c6e 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, > * > * The downside is that we have to touch page->_refcount against each page. > * But we had to alter page->flags anyway. > + * > + * Returns the number of pages moved to the given lru. > */ > > -static void move_active_pages_to_lru(struct lruvec *lruvec, > +static int move_active_pages_to_lru(struct lruvec *lruvec, > struct list_head *list, > struct list_head *pages_to_free, > enum lru_list lru) > @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > unsigned long pgmoved = 0; > struct page *page; > int nr_pages; > + int nr_moved = 0; > > while (!list_empty(list)) { > page = lru_to_page(list); > @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > spin_lock_irq(&pgdat->lru_lock); > } else > list_add(&page->lru, pages_to_free); > + } else { > + nr_moved++; > } > } > > if (!is_active_lru(lru)) > __count_vm_events(PGDEACTIVATE, pgmoved); > + > + return nr_moved; > } > > static void shrink_active_list(unsigned long nr_to_scan, > @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, > LIST_HEAD(l_inactive); > struct page *page; > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; > - unsigned long nr_rotated = 0; > + unsigned long nr_rotated = 0, nr_unevictable = 0; > + unsigned long nr_freed, nr_deactivate, nr_activate; > isolate_mode_t isolate_mode = 0; > int file = is_file_lru(lru); > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > @@ -1935,6 +1943,7 @@ static void shrink_active_list(unsigned long nr_to_scan, > > if (unlikely(!page_evictable(page))) { > putback_lru_page(page); > + nr_unevictable++; > continue; > } > > @@ -1980,13 +1989,16 @@ static void shrink_active_list(unsigned long nr_to_scan, > */ > reclaim_stat->recent_rotated[file] += nr_rotated; > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); Who use nr_active in here? > + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); > spin_unlock_irq(&pgdat->lru_lock); > > mem_cgroup_uncharge_list(&l_hold); > - free_hot_cold_page_list(&l_hold, true); > + nr_freed = free_hot_cold_page_list(&l_hold, true); > + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_freed, > + nr_unevictable, nr_deactivate, nr_rotated, > + sc->priority, file); > } > > /* > -- > 2.10.2 > > -- > 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 S1752044AbcL2Fxh (ORCPT ); Thu, 29 Dec 2016 00:53:37 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:55699 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbcL2Fxg (ORCPT ); Thu, 29 Dec 2016 00:53:36 -0500 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.249.25 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 29 Dec 2016 14:53:29 +0900 From: Minchan Kim To: Michal Hocko CC: , Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Message-ID: <20161229055329.GB1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB05/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/29 14:53:31, Serialize by Router on LGEKRMHUB05/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/29 14:53:31, Serialize complete at 2016/12/29 14:53:31 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 28, 2016 at 04:30:28PM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate shows the number of requested, scanned and taken > pages. This is mostly OK but on 32b systems the number of scanned pages > is quite misleading because it includes both the scanned and skipped > pages. Moreover the skipped part is scaled based on the number of taken > pages. Let's report the exact numbers without any additional logic and > add the number of skipped pages. This should make the reported data much > more easier to interpret. > > Signed-off-by: Michal Hocko Acked-by: 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 S1752276AbcL2GCI (ORCPT ); Thu, 29 Dec 2016 01:02:08 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:59699 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbcL2GCH (ORCPT ); Thu, 29 Dec 2016 01:02:07 -0500 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.249.23 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 29 Dec 2016 15:02:04 +0900 From: Minchan Kim To: Michal Hocko CC: , Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML , Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161229060204.GC1815@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/29 15:02:03, Serialize by Router on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/12/29 15:02:04, Serialize complete at 2016/12/29 15:02:04 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko Not exactly same with this but idea is almost same. I used almost same tracepoint to investigate agging(i.e., deactivating) problem in 32b kernel with node-lru. It was enough. Namely, I didn't need tracepoint in shrink_active_list like your first patch. Your first patch is more straightforwad and information. But as you introduced this patch, I want to ask in here. Isn't it enough with this patch without your first one to find a such problem? Thanks. > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > -- > 2.10.2 > > -- > 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 S1752520AbcL2Hks (ORCPT ); Thu, 29 Dec 2016 02:40:48 -0500 Received: from out4441.biz.mail.alibaba.com ([47.88.44.41]:25260 "EHLO out4441.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752294AbcL2Hko (ORCPT ); Thu, 29 Dec 2016 02:40:44 -0500 X-Greylist: delayed 359 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 02:40:44 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03290;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7Mc1n3s_1482996781; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-2-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-2-mhocko@kernel.org> Subject: Re: [PATCH 1/7] mm, vmscan: remove unused mm_vmscan_memcg_isolate Date: Thu, 29 Dec 2016 15:33:01 +0800 Message-ID: <06d201d261a5$c9248e80$5b6dab80$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wF8CB2zn3x7iTA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > the trace point is not used since 925b7673cce3 ("mm: make per-memcg LRU > lists exclusive") so it can be removed. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531AbcL2Htx (ORCPT ); Thu, 29 Dec 2016 02:49:53 -0500 Received: from out0-133.mail.aliyun.com ([140.205.0.133]:39280 "EHLO out0-133.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752346AbcL2Htw (ORCPT ); Thu, 29 Dec 2016 02:49:52 -0500 X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 02:49:51 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03297;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MiLi89_1482997446; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-3-mhocko@kernel.org> Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Thu, 29 Dec 2016 15:44:06 +0800 Message-ID: <06d301d261a7$558f8ef0$00aeacd0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wIwCfyqn3bfTeA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > the number of scanned, rotated, deactivated and freed pages from the > particular node's active list. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752471AbcL2Hwv (ORCPT ); Thu, 29 Dec 2016 02:52:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:50769 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbcL2Hwu (ORCPT ); Thu, 29 Dec 2016 02:52:50 -0500 Date: Thu, 29 Dec 2016 08:52:46 +0100 From: Michal Hocko To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161229075243.GA29208@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229053359.GA1815@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 29-12-16 14:33:59, Minchan Kim wrote: > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Our reclaim process has several tracepoints to tell us more about how > > things are progressing. We are, however, missing a tracepoint to track > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > the number of scanned, rotated, deactivated and freed pages from the > > particular node's active list. > > > > Signed-off-by: Michal Hocko > > --- > > include/linux/gfp.h | 2 +- > > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > > mm/page_alloc.c | 6 +++++- > > mm/vmscan.c | 22 +++++++++++++++++----- > > 4 files changed, 61 insertions(+), 7 deletions(-) > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > index 4175dca4ac39..61aa9b49e86d 100644 > > --- a/include/linux/gfp.h > > +++ b/include/linux/gfp.h > > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > > extern void __free_pages(struct page *page, unsigned int order); > > extern void free_pages(unsigned long addr, unsigned int order); > > extern void free_hot_cold_page(struct page *page, bool cold); > > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > > > struct page_frag_cache; > > extern void __page_frag_drain(struct page *page, unsigned int order, > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 39bad8921ca1..d34cc0ced2be 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > > show_reclaim_flags(__entry->reclaim_flags)) > > ); > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > + > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > + unsigned long nr_rotated, int priority, int file), > > + > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > I agree it is helpful. And it was when I investigated aging problem of 32bit > when node-lru was introduced. However, the question is we really need all those > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? Dunno. Is it harmful to add this information? I like it more when the numbers just add up and you have a clear picture. You never know what might be useful when debugging a weird behavior. [...] > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > > Who use nr_active in here? this is an omission. I just forgot to add it... Thanks for noticing. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbcL2H5e (ORCPT ); Thu, 29 Dec 2016 02:57:34 -0500 Received: from mx2.suse.de ([195.135.220.15]:50932 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752424AbcL2H5b (ORCPT ); Thu, 29 Dec 2016 02:57:31 -0500 Date: Thu, 29 Dec 2016 08:56:49 +0100 From: Michal Hocko To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161229075649.GB29208@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229060204.GC1815@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 29-12-16 15:02:04, Minchan Kim wrote: > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > the tracepoint to show symbolic names of the lru rather. > > > > Signed-off-by: Michal Hocko > > Not exactly same with this but idea is almost same. > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > in 32b kernel with node-lru. > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > first patch. > Your first patch is more straightforwad and information. But as you introduced > this patch, I want to ask in here. > Isn't it enough with this patch without your first one to find a such problem? I assume this should be a reply to http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? And you are right that for the particular problem it was enough to have a tracepoint inside inactive_list_is_low and shrink_active_list one wasn't really needed. On the other hand aging issues are really hard to debug as well and so I think that both are useful. The first one tell us _why_ we do aging while the later _how_ we do that. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752593AbcL2H5p (ORCPT ); Thu, 29 Dec 2016 02:57:45 -0500 Received: from out0-143.mail.aliyun.com ([140.205.0.143]:52237 "EHLO out0-143.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752450AbcL2H5n (ORCPT ); Thu, 29 Dec 2016 02:57:43 -0500 X-Greylist: delayed 414 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 02:57:43 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03292;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MZvKO-_1482997785; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Date: Thu, 29 Dec 2016 15:49:45 +0800 Message-ID: <06d701d261a8$20082390$60186ab0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wK8wtQvn3J7EKA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate shows the number of requested, scanned and taken > pages. This is mostly OK but on 32b systems the number of scanned pages > is quite misleading because it includes both the scanned and skipped > pages. Moreover the skipped part is scaled based on the number of taken > pages. Let's report the exact numbers without any additional logic and > add the number of skipped pages. This should make the reported data much > more easier to interpret. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752612AbcL2H7r (ORCPT ); Thu, 29 Dec 2016 02:59:47 -0500 Received: from out0-147.mail.aliyun.com ([140.205.0.147]:46515 "EHLO out0-147.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752442AbcL2H7q (ORCPT ); Thu, 29 Dec 2016 02:59:46 -0500 X-Greylist: delayed 328 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 02:59:43 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R781e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03291;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MYz6Si_1482998030; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Thu, 29 Dec 2016 15:53:49 +0800 Message-ID: <06d801d261a8$b1763600$1462a200$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wG47H2xn3qa3PA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:30 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752621AbcL2IGQ (ORCPT ); Thu, 29 Dec 2016 03:06:16 -0500 Received: from out0-158.mail.aliyun.com ([140.205.0.158]:59228 "EHLO out0-158.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394AbcL2IGP (ORCPT ); Thu, 29 Dec 2016 03:06:15 -0500 X-Greylist: delayed 316 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 03:06:15 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03289;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MiAg1m_1482998433; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-6-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-6-mhocko@kernel.org> Subject: Re: [PATCH 5/7] mm, vmscan: extract shrink_page_list reclaim counters into a struct Date: Thu, 29 Dec 2016 16:00:33 +0800 Message-ID: <06d901d261a9$a2277d70$e6767850$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wJJAG2xn3YcC1A= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > shrink_page_list returns quite some counters back to its caller. Extract > the existing 5 into struct reclaim_stat because this makes the code > easier to follow and also allows further counters to be returned. > > While we are at it, make all of them unsigned rather than unsigned long > as we do not really need full 64b for them (we never scan more than > SWAP_CLUSTER_MAX pages at once). This should reduce some stack space. > > This patch shouldn't introduce any functional change. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497AbcL2ILe (ORCPT ); Thu, 29 Dec 2016 03:11:34 -0500 Received: from out0-154.mail.aliyun.com ([140.205.0.154]:39040 "EHLO out0-154.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbcL2ILd (ORCPT ); Thu, 29 Dec 2016 03:11:33 -0500 X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 03:11:32 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03293;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7Mc1pa2_1482998749; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-7-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-7-mhocko@kernel.org> Subject: Re: [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint Date: Thu, 29 Dec 2016 16:05:49 +0800 Message-ID: <06da01d261aa$5e7b01e0$1b7105a0$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wH1h+Bzn3i5bOA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_shrink_inactive will currently report the number of > scanned and reclaimed pages. This doesn't give us an idea how the > reclaim went except for the overall effectiveness though. Export > and show other counters which will tell us why we couldn't reclaim > some pages. > - nr_dirty, nr_writeback, nr_congested and nr_immediate tells > us how many pages are blocked due to IO > - nr_activate tells us how many pages were moved to the active > list > - nr_ref_keep reports how many pages are kept on the LRU due > to references (mostly for the file pages which are about to > go for another round through the inactive list) > - nr_unmap_fail - how many pages failed to unmap > > All these are rather low level so they might change in future but the > tracepoint is already implementation specific so no tools should be > depending on its stability. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752555AbcL2IZM (ORCPT ); Thu, 29 Dec 2016 03:25:12 -0500 Received: from out0-142.mail.aliyun.com ([140.205.0.142]:43001 "EHLO out0-142.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752515AbcL2IZL (ORCPT ); Thu, 29 Dec 2016 03:25:11 -0500 X-Greylist: delayed 316 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Dec 2016 03:25:10 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03302;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MaxhG4_1482999565; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , Cc: "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" , "'Michal Hocko'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-8-mhocko@kernel.org> In-Reply-To: <20161228153032.10821-8-mhocko@kernel.org> Subject: Re: [PATCH 7/7] mm, vmscan: add mm_vmscan_inactive_list_is_low tracepoint Date: Thu, 29 Dec 2016 16:19:25 +0800 Message-ID: <06db01d261ac$44a57910$cdf06b30$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wIPSXxhn3ftdtA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, December 28, 2016 11:31 PM Michal Hocko wrote: > From: Michal Hocko > > Currently we have tracepoints for both active and inactive LRU lists > reclaim but we do not have any which would tell us why we we decided to > age the active list. Without that it is quite hard to diagnose > active/inactive lists balancing. Add mm_vmscan_inactive_list_is_low > tracepoint to tell us this information. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753287AbcL3Bs5 (ORCPT ); Thu, 29 Dec 2016 20:48:57 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:45797 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751545AbcL3Bs4 (ORCPT ); Thu, 29 Dec 2016 20:48:56 -0500 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 30 Dec 2016 10:48:53 +0900 From: Minchan Kim To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230014853.GA4184@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229075243.GA29208@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > things are progressing. We are, however, missing a tracepoint to track > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > the number of scanned, rotated, deactivated and freed pages from the > > > particular node's active list. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > include/linux/gfp.h | 2 +- > > > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > > > mm/page_alloc.c | 6 +++++- > > > mm/vmscan.c | 22 +++++++++++++++++----- > > > 4 files changed, 61 insertions(+), 7 deletions(-) > > > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > > index 4175dca4ac39..61aa9b49e86d 100644 > > > --- a/include/linux/gfp.h > > > +++ b/include/linux/gfp.h > > > @@ -503,7 +503,7 @@ void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask); > > > extern void __free_pages(struct page *page, unsigned int order); > > > extern void free_pages(unsigned long addr, unsigned int order); > > > extern void free_hot_cold_page(struct page *page, bool cold); > > > -extern void free_hot_cold_page_list(struct list_head *list, bool cold); > > > +extern int free_hot_cold_page_list(struct list_head *list, bool cold); > > > > > > struct page_frag_cache; > > > extern void __page_frag_drain(struct page *page, unsigned int order, > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 39bad8921ca1..d34cc0ced2be 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > > > show_reclaim_flags(__entry->reclaim_flags)) > > > ); > > > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > + > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > + unsigned long nr_rotated, int priority, int file), > > > + > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > when node-lru was introduced. However, the question is we really need all those > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > Dunno. Is it harmful to add this information? I like it more when the > numbers just add up and you have a clear picture. You never know what > might be useful when debugging a weird behavior. Michal, I'm not huge fan of "might be useful" although it's a small piece of code. It adds just all of kinds overheads (memory footprint, runtime performance, maintainance) without any proved benefit. If we allow such things, people would start adding more things with just "why not, it might be useful. you never know the future" and it ends up making linux fiction novel mess. If it's necessary, someday, someone will catch up and will send or ask patch with detailed description "why the stat is important and how it is good for us to solve some problem". From that, we can learn workload, way to solve the problem and git history has the valuable description so new comers can keep the community up easily. So, finally, overheads are justified and get merged. Please add must-have for your goal described. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753353AbcL3B42 (ORCPT ); Thu, 29 Dec 2016 20:56:28 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:59025 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751456AbcL3B41 (ORCPT ); Thu, 29 Dec 2016 20:56:27 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 30 Dec 2016 10:56:25 +0900 From: Minchan Kim To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161230015625.GB4184@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> <20161229075649.GB29208@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229075649.GB29208@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote: > On Thu 29-12-16 15:02:04, Minchan Kim wrote: > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > from is file or anonymous but we do not know which LRU this is. It is > > > useful to know whether the list is file or anonymous as well. Change > > > the tracepoint to show symbolic names of the lru rather. > > > > > > Signed-off-by: Michal Hocko > > > > Not exactly same with this but idea is almost same. > > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > > in 32b kernel with node-lru. > > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > > first patch. > > Your first patch is more straightforwad and information. But as you introduced > > this patch, I want to ask in here. > > Isn't it enough with this patch without your first one to find a such problem? > > I assume this should be a reply to > http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? I don't know my browser says "No such Message-ID known" > And you are right that for the particular problem it was enough to have > a tracepoint inside inactive_list_is_low and shrink_active_list one > wasn't really needed. On the other hand aging issues are really hard to What kinds of aging issue? What's the problem? How such tracepoint can help? Please describe. > debug as well and so I think that both are useful. The first one tell us > _why_ we do aging while the later _how_ we do that. Solve reported problem first you already knew. It would be no doubt to merge and then send other patches about "it might be useful" with useful scenario. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbcL3JLW (ORCPT ); Fri, 30 Dec 2016 04:11:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:43420 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751820AbcL3JLU (ORCPT ); Fri, 30 Dec 2016 04:11:20 -0500 Date: Fri, 30 Dec 2016 09:11:17 +0000 From: Mel Gorman To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230091117.nkxn3bnhle3bofhw@suse.de> References: <20161228153032.10821-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20161228153032.10821-1-mhocko@kernel.org> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > Hi, > while debugging [1] I've realized that there is some room for > improvements in the tracepoints set we offer currently. I had hard times > to make any conclusion from the existing ones. The resulting problem > turned out to be active list aging [2] and we are missing at least two > tracepoints to debug such a problem. > > Some existing tracepoints could export more information to see _why_ the > reclaim progress cannot be made not only _how much_ we could reclaim. > The later could be seen quite reasonably from the vmstat counters > already. It can be argued that we are showing too many implementation > details in those tracepoints but I consider them way too lowlevel > already to be usable by any kernel independent userspace. I would be > _really_ surprised if anything but debugging tools have used them. > > Any feedback is highly appreciated. > There is some minor overhead introduced in some paths regardless of whether the tracepoints are active or not but I suspect it's negligible in the context of the overhead of reclaim in general so; Acked-by: Mel Gorman -- Mel Gorman SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752230AbcL3J0n (ORCPT ); Fri, 30 Dec 2016 04:26:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:44182 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751820AbcL3J0m (ORCPT ); Fri, 30 Dec 2016 04:26:42 -0500 Date: Fri, 30 Dec 2016 10:26:37 +0100 From: Michal Hocko To: Minchan Kim , Hillf Danton Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230092636.GA13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230014853.GA4184@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-12-16 10:48:53, Minchan Kim wrote: > On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: [...] > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > > + > > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > > + unsigned long nr_rotated, int priority, int file), > > > > + > > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > > when node-lru was introduced. However, the question is we really need all those > > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > > > Dunno. Is it harmful to add this information? I like it more when the > > numbers just add up and you have a clear picture. You never know what > > might be useful when debugging a weird behavior. > > Michal, I'm not huge fan of "might be useful" although it's a small piece of code. But these are tracepoints. One of their primary reasons to exist is to help debug things. And it is really hard to predict what might be useful in advance. It is not like the patch would export numbers which would be irrelevant to the reclaim. > It adds just all of kinds overheads (memory footprint, runtime performance, > maintainance) without any proved benefit. Does it really add any measurable overhead or the maintenance burden? I think the only place we could argue about is free_hot_cold_page_list which is used in hot paths. I think we can sacrifice it. The same for culled unevictable pages. We wouldn't know what is the missing part nr_taken-(nr_activate+nr_deactivate) because it could be either freed or moved to the unevictable list but that could be handled in a separate tracepoint in putback_lru_page which sounds like a useful thing I guess. > If we allow such things, people would start adding more things with just "why not, > it might be useful. you never know the future" and it ends up making linux fiction > novel mess. I agree with this concern in general, but is this the case in this particular case? > If it's necessary, someday, someone will catch up and will send or ask patch with > detailed description "why the stat is important and how it is good for us to solve > some problem". I can certainly enhance the changelog. See below. > From that, we can learn workload, way to solve the problem and git > history has the valuable description so new comers can keep the community up easily. > So, finally, overheads are justified and get merged. > > Please add must-have for your goal described. My primary point is that tracepoints which do not give us a good picture are quite useless and force us to add trace_printk or other means to give us further information. Then I wonder why to have an incomplete tracepoint at all. Anyway, what do you think about this updated patch? I have kept Hillf's A-b so please let me know if it is no longer valid. --- >>From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Tue, 27 Dec 2016 13:18:20 +0100 Subject: [PATCH] mm, vmscan: add active list aging tracepoint Our reclaim process has several tracepoints to tell us more about how things are progressing. We are, however, missing a tracepoint to track active list aging. Introduce mm_vmscan_lru_shrink_active which reports the number of - nr_scanned, nr_taken pages to tell us the LRU isolation effectiveness. - nr_rotated pages which tells us that we are hitting referenced pages which are deactivated. If this is a large part of the reported nr_deactivated pages then the active list is too small - nr_activated pages which tells us how many pages are keept on the active list - mostly exec pages. A high number can indicate that we might be trashing on executables. Changes since v1 - report nr_taken pages as per Minchan - report nr_activated as per Minchan - do not report nr_freed pages because that would add a tiny overhead to free_hot_cold_page_list which is a hot path - do not report nr_unevictable because we can report this number via a different and more generic tracepoint in putback_lru_page - fix move_active_pages_to_lru to report proper page count when we hit into large pages Acked-by: Hillf Danton Signed-off-by: Michal Hocko --- include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 18 ++++++++++++++---- 2 files changed, 52 insertions(+), 4 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 39bad8921ca1..f9ef242ece1b 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_vmscan_lru_shrink_active, + + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_taken, + unsigned long nr_activate, unsigned long nr_deactivated, + unsigned long nr_rotated, int priority, int file), + + TP_ARGS(nid, nr_scanned, nr_taken, nr_activate, nr_deactivated, nr_rotated, priority, file), + + TP_STRUCT__entry( + __field(int, nid) + __field(unsigned long, nr_scanned) + __field(unsigned long, nr_taken) + __field(unsigned long, nr_activate) + __field(unsigned long, nr_deactivated) + __field(unsigned long, nr_rotated) + __field(int, priority) + __field(int, reclaim_flags) + ), + + TP_fast_assign( + __entry->nid = nid; + __entry->nr_scanned = nr_scanned; + __entry->nr_taken = nr_taken; + __entry->nr_activate = nr_activate; + __entry->nr_deactivated = nr_deactivated; + __entry->nr_rotated = nr_rotated; + __entry->priority = priority; + __entry->reclaim_flags = trace_shrink_flags(file); + ), + + TP_printk("nid=%d nr_scanned=%ld nr_taken=%ld nr_activated=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", + __entry->nid, + __entry->nr_scanned, __entry->nr_taken, + __entry->nr_activate, __entry->nr_deactivated, __entry->nr_rotated, + __entry->priority, + show_reclaim_flags(__entry->reclaim_flags)) +); + #endif /* _TRACE_VMSCAN_H */ /* This part must be outside protection */ diff --git a/mm/vmscan.c b/mm/vmscan.c index c4abf08861d2..4da4d8d0496c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, * * The downside is that we have to touch page->_refcount against each page. * But we had to alter page->flags anyway. + * + * Returns the number of pages moved to the given lru. */ -static void move_active_pages_to_lru(struct lruvec *lruvec, +static unsigned move_active_pages_to_lru(struct lruvec *lruvec, struct list_head *list, struct list_head *pages_to_free, enum lru_list lru) @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, unsigned long pgmoved = 0; struct page *page; int nr_pages; + int nr_moved = 0; while (!list_empty(list)) { page = lru_to_page(list); @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, spin_lock_irq(&pgdat->lru_lock); } else list_add(&page->lru, pages_to_free); + } else { + nr_moved += nr_pages; } } if (!is_active_lru(lru)) __count_vm_events(PGDEACTIVATE, pgmoved); + + return nr_moved; } static void shrink_active_list(unsigned long nr_to_scan, @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, LIST_HEAD(l_inactive); struct page *page; struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; - unsigned long nr_rotated = 0; + unsigned nr_deactivate, nr_activate; + unsigned nr_rotated = 0; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); @@ -1980,13 +1988,15 @@ static void shrink_active_list(unsigned long nr_to_scan, */ reclaim_stat->recent_rotated[file] += nr_rotated; - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); spin_unlock_irq(&pgdat->lru_lock); mem_cgroup_uncharge_list(&l_hold); free_hot_cold_page_list(&l_hold, true); + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_taken, + nr_activate, nr_deactivate, nr_rotated, sc->priority, file); } /* -- 2.10.2 -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751886AbcL3JdP (ORCPT ); Fri, 30 Dec 2016 04:33:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:44622 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbcL3JdO (ORCPT ); Fri, 30 Dec 2016 04:33:14 -0500 Date: Fri, 30 Dec 2016 10:33:10 +0100 From: Michal Hocko To: Minchan Kim Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20161230093308.GB13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <20161229060204.GC1815@bbox> <20161229075649.GB29208@dhcp22.suse.cz> <20161230015625.GB4184@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230015625.GB4184@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-12-16 10:56:25, Minchan Kim wrote: > On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote: > > On Thu 29-12-16 15:02:04, Minchan Kim wrote: > > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > > from is file or anonymous but we do not know which LRU this is. It is > > > > useful to know whether the list is file or anonymous as well. Change > > > > the tracepoint to show symbolic names of the lru rather. > > > > > > > > Signed-off-by: Michal Hocko > > > > > > Not exactly same with this but idea is almost same. > > > I used almost same tracepoint to investigate agging(i.e., deactivating) problem > > > in 32b kernel with node-lru. > > > It was enough. Namely, I didn't need tracepoint in shrink_active_list like your > > > first patch. > > > Your first patch is more straightforwad and information. But as you introduced > > > this patch, I want to ask in here. > > > Isn't it enough with this patch without your first one to find a such problem? > > > > I assume this should be a reply to > > http://lkml.kernel.org/r/20161228153032.10821-8-mhocko@kernel.org, right? > > I don't know my browser says "No such Message-ID known" Hmm, not sure why it didn't get archived at lkml.kernel.org. I meant https://lkml.org/lkml/2016/12/28/167 > > And you are right that for the particular problem it was enough to have > > a tracepoint inside inactive_list_is_low and shrink_active_list one > > wasn't really needed. On the other hand aging issues are really hard to > > What kinds of aging issue? What's the problem? How such tracepoint can help? > Please describe. If you do not see that active list is shrunk then you do not know why it is not shrunk. It might be a active/inactive ratio or just a plan bug like the 32b issue me and you were debugging. > > debug as well and so I think that both are useful. The first one tell us > > _why_ we do aging while the later _how_ we do that. > > Solve reported problem first you already knew. It would be no doubt > to merge and then send other patches about "it might be useful" with > useful scenario. I am not sure I understand. The point of tracepoints is to be pro-actively helpful not only to add something that has been useful in one-off cases. A particular debugging session might be really helpful to tell us what we are missing and this was the case here to a large part. Once I was looking there I just wanted to save the pain of adding more debugging information in future and allow people to debug their issue without forcing them to recompile the kernel. I believe this is one of the strong usecases for tracepoints in the first place. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752349AbcL3JhA (ORCPT ); Fri, 30 Dec 2016 04:37:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:44775 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbcL3Jg6 (ORCPT ); Fri, 30 Dec 2016 04:36:58 -0500 Date: Fri, 30 Dec 2016 10:36:55 +0100 From: Michal Hocko To: Mel Gorman Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230093654.GC13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161230091117.nkxn3bnhle3bofhw@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230091117.nkxn3bnhle3bofhw@suse.de> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-12-16 09:11:17, Mel Gorman wrote: > On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > > Hi, > > while debugging [1] I've realized that there is some room for > > improvements in the tracepoints set we offer currently. I had hard times > > to make any conclusion from the existing ones. The resulting problem > > turned out to be active list aging [2] and we are missing at least two > > tracepoints to debug such a problem. > > > > Some existing tracepoints could export more information to see _why_ the > > reclaim progress cannot be made not only _how much_ we could reclaim. > > The later could be seen quite reasonably from the vmstat counters > > already. It can be argued that we are showing too many implementation > > details in those tracepoints but I consider them way too lowlevel > > already to be usable by any kernel independent userspace. I would be > > _really_ surprised if anything but debugging tools have used them. > > > > Any feedback is highly appreciated. > > > > There is some minor overhead introduced in some paths regardless of > whether the tracepoints are active or not but I suspect it's negligible > in the context of the overhead of reclaim in general so; I will work on improving some of them. E.g. I've dropped the change to free_hot_cold_page_list because that is indeed a hot path but other than that there shouldn't be any even medium hot path which should see any overhead I can see. If you are aware of any, please let me know and I will think about how to improve it. > Acked-by: Mel Gorman Thanks! -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752169AbcL3JoO (ORCPT ); Fri, 30 Dec 2016 04:44:14 -0500 Received: from out0-140.mail.aliyun.com ([140.205.0.140]:38230 "EHLO out0-140.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751691AbcL3JoN (ORCPT ); Fri, 30 Dec 2016 04:44:13 -0500 X-Greylist: delayed 316 seconds by postgrey-1.27 at vger.kernel.org; Fri, 30 Dec 2016 04:44:11 EST X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03302;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.7MxCfF7_1483090708; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , "'Minchan Kim'" Cc: , "'Andrew Morton'" , "'Mel Gorman'" , "'Johannes Weiner'" , "'Vlastimil Babka'" , "'Rik van Riel'" , "'LKML'" References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> In-Reply-To: <20161230092636.GA13301@dhcp22.suse.cz> Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Date: Fri, 30 Dec 2016 17:38:28 +0800 Message-ID: <001b01d26280$7a5ee120$6f1ca360$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKdd06YOfI90de32HGjIBSPbRj/+wIwCfyqAjee/P4CW13RqQIHeUPfAbYf/YSfNgvbsA== Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, December 30, 2016 5:27 PM Michal Hocko wrote: > Anyway, what do you think about this updated patch? I have kept Hillf's > A-b so please let me know if it is no longer valid. > My mind is not changed:) Happy new year folks! Hillf From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753614AbcL3KUt (ORCPT ); Fri, 30 Dec 2016 05:20:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:46237 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752635AbcL3KUs (ORCPT ); Fri, 30 Dec 2016 05:20:48 -0500 Date: Fri, 30 Dec 2016 10:20:45 +0000 From: Mel Gorman To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Message-ID: <20161230102045.y2fiszc2o2uqmny4@suse.de> References: <20161228153032.10821-1-mhocko@kernel.org> <20161230091117.nkxn3bnhle3bofhw@suse.de> <20161230093654.GC13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20161230093654.GC13301@dhcp22.suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 30, 2016 at 10:36:55AM +0100, Michal Hocko wrote: > On Fri 30-12-16 09:11:17, Mel Gorman wrote: > > On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote: > > > Hi, > > > while debugging [1] I've realized that there is some room for > > > improvements in the tracepoints set we offer currently. I had hard times > > > to make any conclusion from the existing ones. The resulting problem > > > turned out to be active list aging [2] and we are missing at least two > > > tracepoints to debug such a problem. > > > > > > Some existing tracepoints could export more information to see _why_ the > > > reclaim progress cannot be made not only _how much_ we could reclaim. > > > The later could be seen quite reasonably from the vmstat counters > > > already. It can be argued that we are showing too many implementation > > > details in those tracepoints but I consider them way too lowlevel > > > already to be usable by any kernel independent userspace. I would be > > > _really_ surprised if anything but debugging tools have used them. > > > > > > Any feedback is highly appreciated. > > > > > > > There is some minor overhead introduced in some paths regardless of > > whether the tracepoints are active or not but I suspect it's negligible > > in the context of the overhead of reclaim in general so; > > I will work on improving some of them. E.g. I've dropped the change to > free_hot_cold_page_list because that is indeed a hot path but other than > that there shouldn't be any even medium hot path which should see any > overhead I can see. If you are aware of any, please let me know and I > will think about how to improve it. > I didn't spot one. The path where I saw the most overhead is already quite heavy. -- Mel Gorman SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754322AbcL3QFE (ORCPT ); Fri, 30 Dec 2016 11:05:04 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:52715 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753848AbcL3QFD (ORCPT ); Fri, 30 Dec 2016 11:05:03 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Sat, 31 Dec 2016 01:04:56 +0900 From: Minchan Kim To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230160456.GA7267@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230092636.GA13301@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 30, 2016 at 10:26:37AM +0100, Michal Hocko wrote: > On Fri 30-12-16 10:48:53, Minchan Kim wrote: > > On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote: > > > On Thu 29-12-16 14:33:59, Minchan Kim wrote: > > > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote: > [...] > > > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > > > > > + > > > > > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_freed, > > > > > + unsigned long nr_unevictable, unsigned long nr_deactivated, > > > > > + unsigned long nr_rotated, int priority, int file), > > > > > + > > > > > + TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, nr_deactivated, nr_rotated, priority, file), > > > > > > > > I agree it is helpful. And it was when I investigated aging problem of 32bit > > > > when node-lru was introduced. However, the question is we really need all those > > > > kinds of information? just enough with nr_taken, nr_deactivated, priority, file? > > > > > > Dunno. Is it harmful to add this information? I like it more when the > > > numbers just add up and you have a clear picture. You never know what > > > might be useful when debugging a weird behavior. > > > > Michal, I'm not huge fan of "might be useful" although it's a small piece of code. > > But these are tracepoints. One of their primary reasons to exist is > to help debug things. And it is really hard to predict what might be > useful in advance. It is not like the patch would export numbers which > would be irrelevant to the reclaim. What's different? Please think over if everyone says like that they want to add something with the reason "it's tracepoint which helps dubug and we cannot assume what might be useful in the future." > > > It adds just all of kinds overheads (memory footprint, runtime performance, > > maintainance) without any proved benefit. > > Does it really add any measurable overhead or the maintenance burden? I Don't limit your thought in this particular case and expand the idea to others who want to see random value via tracepoint with just "might-be- good". We will lose the reason to prevent that trend if we merge any tracepoint expansion patch with just "might-be-useful" reason. Finally, that would bite us. > think the only place we could argue about is free_hot_cold_page_list > which is used in hot paths. The point of view about shrinking active list, what we want to know is just (nr_taken|nr_deactivated|priority|file) and it's enough, I think. So, if you want to add nr_freed, nr_unevictable, nr_rotated please, describe "what problem we can solve with those each numbers". > > I think we can sacrifice it. The same for culled unevictable > pages. We wouldn't know what is the missing part > nr_taken-(nr_activate+nr_deactivate) because it could be either freed or > moved to the unevictable list but that could be handled in a separate > tracepoint in putback_lru_page which sounds like a useful thing I guess. > > > If we allow such things, people would start adding more things with just "why not, > > it might be useful. you never know the future" and it ends up making linux fiction > > novel mess. > > I agree with this concern in general, but is this the case in this > particular case? I believe it's not different. > > > If it's necessary, someday, someone will catch up and will send or ask patch with > > detailed description "why the stat is important and how it is good for us to solve > > some problem". > > I can certainly enhance the changelog. See below. > > > From that, we can learn workload, way to solve the problem and git > > history has the valuable description so new comers can keep the community up easily. > > So, finally, overheads are justified and get merged. > > > > Please add must-have for your goal described. > > My primary point is that tracepoints which do not give us a good picture > are quite useless and force us to add trace_printk or other means to > give us further information. Then I wonder why to have an incomplete > tracepoint at all. > > Anyway, what do you think about this updated patch? I have kept Hillf's > A-b so please let me know if it is no longer valid. > --- > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 27 Dec 2016 13:18:20 +0100 > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > Our reclaim process has several tracepoints to tell us more about how > things are progressing. We are, however, missing a tracepoint to track > active list aging. Introduce mm_vmscan_lru_shrink_active which reports I agree this part. > the number of > - nr_scanned, nr_taken pages to tell us the LRU isolation > effectiveness. I agree nr_taken for knowing shrinking effectiveness but don't agree nr_scanned. If we want to know LRU isolation effectiveness with nr_scanned and nr_taken, isolate_lru_pages will do. > - nr_rotated pages which tells us that we are hitting referenced > pages which are deactivated. If this is a large part of the > reported nr_deactivated pages then the active list is too small It might be but not exactly. If your goal is to know LRU size, it can be done in get_scan_count. I tend to agree LRU size is helpful for performance analysis because decreased LRU size signals memory shortage then performance drop. > - nr_activated pages which tells us how many pages are keept on the kept > active list - mostly exec pages. A high number can indicate file-based exec pages > that we might be trashing on executables. And welcome to drop nr_unevictable, nr_freed. I will be off until next week monday so please understand if my response is slow. Thanks. > > Changes since v1 > - report nr_taken pages as per Minchan > - report nr_activated as per Minchan > - do not report nr_freed pages because that would add a tiny overhead to > free_hot_cold_page_list which is a hot path > - do not report nr_unevictable because we can report this number via a > different and more generic tracepoint in putback_lru_page > - fix move_active_pages_to_lru to report proper page count when we hit > into large pages > > Acked-by: Hillf Danton > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 38 ++++++++++++++++++++++++++++++++++++++ > mm/vmscan.c | 18 ++++++++++++++---- > 2 files changed, 52 insertions(+), 4 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 39bad8921ca1..f9ef242ece1b 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -363,6 +363,44 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, > show_reclaim_flags(__entry->reclaim_flags)) > ); > > +TRACE_EVENT(mm_vmscan_lru_shrink_active, > + > + TP_PROTO(int nid, unsigned long nr_scanned, unsigned long nr_taken, > + unsigned long nr_activate, unsigned long nr_deactivated, > + unsigned long nr_rotated, int priority, int file), > + > + TP_ARGS(nid, nr_scanned, nr_taken, nr_activate, nr_deactivated, nr_rotated, priority, file), > + > + TP_STRUCT__entry( > + __field(int, nid) > + __field(unsigned long, nr_scanned) > + __field(unsigned long, nr_taken) > + __field(unsigned long, nr_activate) > + __field(unsigned long, nr_deactivated) > + __field(unsigned long, nr_rotated) > + __field(int, priority) > + __field(int, reclaim_flags) > + ), > + > + TP_fast_assign( > + __entry->nid = nid; > + __entry->nr_scanned = nr_scanned; > + __entry->nr_taken = nr_taken; > + __entry->nr_activate = nr_activate; > + __entry->nr_deactivated = nr_deactivated; > + __entry->nr_rotated = nr_rotated; > + __entry->priority = priority; > + __entry->reclaim_flags = trace_shrink_flags(file); > + ), > + > + TP_printk("nid=%d nr_scanned=%ld nr_taken=%ld nr_activated=%ld nr_deactivated=%ld nr_rotated=%ld priority=%d flags=%s", > + __entry->nid, > + __entry->nr_scanned, __entry->nr_taken, > + __entry->nr_activate, __entry->nr_deactivated, __entry->nr_rotated, > + __entry->priority, > + show_reclaim_flags(__entry->reclaim_flags)) > +); > + > #endif /* _TRACE_VMSCAN_H */ > > /* This part must be outside protection */ > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c4abf08861d2..4da4d8d0496c 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1846,9 +1846,11 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, > * > * The downside is that we have to touch page->_refcount against each page. > * But we had to alter page->flags anyway. > + * > + * Returns the number of pages moved to the given lru. > */ > > -static void move_active_pages_to_lru(struct lruvec *lruvec, > +static unsigned move_active_pages_to_lru(struct lruvec *lruvec, > struct list_head *list, > struct list_head *pages_to_free, > enum lru_list lru) > @@ -1857,6 +1859,7 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > unsigned long pgmoved = 0; > struct page *page; > int nr_pages; > + int nr_moved = 0; > > while (!list_empty(list)) { > page = lru_to_page(list); > @@ -1882,11 +1885,15 @@ static void move_active_pages_to_lru(struct lruvec *lruvec, > spin_lock_irq(&pgdat->lru_lock); > } else > list_add(&page->lru, pages_to_free); > + } else { > + nr_moved += nr_pages; > } > } > > if (!is_active_lru(lru)) > __count_vm_events(PGDEACTIVATE, pgmoved); > + > + return nr_moved; > } > > static void shrink_active_list(unsigned long nr_to_scan, > @@ -1902,7 +1909,8 @@ static void shrink_active_list(unsigned long nr_to_scan, > LIST_HEAD(l_inactive); > struct page *page; > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; > - unsigned long nr_rotated = 0; > + unsigned nr_deactivate, nr_activate; > + unsigned nr_rotated = 0; > isolate_mode_t isolate_mode = 0; > int file = is_file_lru(lru); > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > @@ -1980,13 +1988,15 @@ static void shrink_active_list(unsigned long nr_to_scan, > */ > reclaim_stat->recent_rotated[file] += nr_rotated; > > - move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > - move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > + nr_activate = move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru); > + nr_deactivate = move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE); > __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken); > spin_unlock_irq(&pgdat->lru_lock); > > mem_cgroup_uncharge_list(&l_hold); > free_hot_cold_page_list(&l_hold, true); > + trace_mm_vmscan_lru_shrink_active(pgdat->node_id, nr_scanned, nr_taken, > + nr_activate, nr_deactivate, nr_rotated, sc->priority, file); > } > > /* > -- > 2.10.2 > > > -- > Michal Hocko > SUSE Labs > > -- > 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 S1751774AbcL3Qhs (ORCPT ); Fri, 30 Dec 2016 11:37:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:58995 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750984AbcL3Qhr (ORCPT ); Fri, 30 Dec 2016 11:37:47 -0500 Date: Fri, 30 Dec 2016 17:37:42 +0100 From: Michal Hocko To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230163742.GK13301@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230160456.GA7267@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 31-12-16 01:04:56, Minchan Kim wrote: [...] > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > Our reclaim process has several tracepoints to tell us more about how > > things are progressing. We are, however, missing a tracepoint to track > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > I agree this part. > > > the number of > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > effectiveness. > > I agree nr_taken for knowing shrinking effectiveness but don't > agree nr_scanned. If we want to know LRU isolation effectiveness > with nr_scanned and nr_taken, isolate_lru_pages will do. Yes it will. On the other hand the number is there and there is no additional overhead, maintenance or otherwise, to provide that number. The inactive counterpart does that for quite some time already. So why exactly does that matter? Don't take me wrong but isn't this more on a nit picking side than necessary? Or do I just misunderstand your concenrs? It is not like we are providing a stable user API as the tracepoint is clearly implementation specific and not something to be used for anything other than debugging. > > - nr_rotated pages which tells us that we are hitting referenced > > pages which are deactivated. If this is a large part of the > > reported nr_deactivated pages then the active list is too small > > It might be but not exactly. If your goal is to know LRU size, it can be > done in get_scan_count. I tend to agree LRU size is helpful for > performance analysis because decreased LRU size signals memory shortage > then performance drop. No, I am not really interested in the exact size but rather to allow to find whether we are aging the active list too early... > > > - nr_activated pages which tells us how many pages are keept on the > kept fixed > > > active list - mostly exec pages. A high number can indicate > > file-based exec pages OK, fixed > > > that we might be trashing on executables. > > And welcome to drop nr_unevictable, nr_freed. > > I will be off until next week monday so please understand if my response > is slow. There is no reason to hurry... -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752056AbcL3Raa (ORCPT ); Fri, 30 Dec 2016 12:30:30 -0500 Received: from mx2.suse.de ([195.135.220.15]:60490 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbcL3Ra3 (ORCPT ); Fri, 30 Dec 2016 12:30:29 -0500 Date: Fri, 30 Dec 2016 18:30:24 +0100 From: Michal Hocko To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20161230173023.GA4962@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230163742.GK13301@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-12-16 17:37:42, Michal Hocko wrote: > On Sat 31-12-16 01:04:56, Minchan Kim wrote: [...] > > > - nr_rotated pages which tells us that we are hitting referenced > > > pages which are deactivated. If this is a large part of the > > > reported nr_deactivated pages then the active list is too small > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > done in get_scan_count. I tend to agree LRU size is helpful for > > performance analysis because decreased LRU size signals memory shortage > > then performance drop. > > No, I am not really interested in the exact size but rather to allow to > find whether we are aging the active list too early... But thinking about that some more, maybe sticking with the nr_rotated terminology is rather confusing and displaying the value as nr_referenced would be more clear. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753187AbdACFDi (ORCPT ); Tue, 3 Jan 2017 00:03:38 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:55410 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbdACFDa (ORCPT ); Tue, 3 Jan 2017 00:03:30 -0500 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Tue, 3 Jan 2017 14:03:28 +0900 From: Minchan Kim To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170103050328.GA15700@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161230163742.GK13301@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > [...] > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > From: Michal Hocko > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > things are progressing. We are, however, missing a tracepoint to track > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > I agree this part. > > > > > the number of > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > effectiveness. > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > agree nr_scanned. If we want to know LRU isolation effectiveness > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > Yes it will. On the other hand the number is there and there is no > additional overhead, maintenance or otherwise, to provide that number. You are adding some instructions, how can you imagine it's no overhead? Let's say whether it's measurable. Although it's not big in particular case, it would be measurable if everyone start to say like that "it's trivial so what's the problem adding a few instructions although it was duplicated?" You already said "LRU isolate effectiveness". It should be done in there, isolate_lru_pages and we have been. You need another reasons if you want to add the duplicated work, strongly. > The inactive counterpart does that for quite some time already. So why It couldn't be a reason. If it was duplicated in there, it would be better to fix it rather than adding more duplciated work to match both sides. > exactly does that matter? Don't take me wrong but isn't this more on a > nit picking side than necessary? Or do I just misunderstand your > concenrs? It is not like we are providing a stable user API as the My concern is that I don't see what we can get benefit from those duplicated work. If it doesn't give benefit to us, I don't want to add. I hope you think another reasonable reasons. > tracepoint is clearly implementation specific and not something to be > used for anything other than debugging. My point is we already had things "LRU isolation effectivness". Namely, isolate_lru_pages. > > > > - nr_rotated pages which tells us that we are hitting referenced > > > pages which are deactivated. If this is a large part of the > > > reported nr_deactivated pages then the active list is too small > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > done in get_scan_count. I tend to agree LRU size is helpful for > > performance analysis because decreased LRU size signals memory shortage > > then performance drop. > > No, I am not really interested in the exact size but rather to allow to > find whether we are aging the active list too early... Could you elaborate it more that how we can get active list early aging with nr_rotated? 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 S934470AbdACIVt (ORCPT ); Tue, 3 Jan 2017 03:21:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:35471 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934093AbdACIV1 (ORCPT ); Tue, 3 Jan 2017 03:21:27 -0500 Date: Tue, 3 Jan 2017 09:21:22 +0100 From: Michal Hocko To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170103082122.GA30111@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103050328.GA15700@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 14:03:28, Minchan Kim wrote: > Hi Michal, > > On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > > [...] > > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > > From: Michal Hocko > > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > > things are progressing. We are, however, missing a tracepoint to track > > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > > > I agree this part. > > > > > > > the number of > > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > > effectiveness. > > > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > > agree nr_scanned. If we want to know LRU isolation effectiveness > > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > > > Yes it will. On the other hand the number is there and there is no > > additional overhead, maintenance or otherwise, to provide that number. > > You are adding some instructions, how can you imagine it's no overhead? There should be close to zero overhead when the tracepoint is disabled (we pay only one more argument when the function is called). Is this really worth discussing in this cold path? We are talking about the reclaim here. > Let's say whether it's measurable. Although it's not big in particular case, > it would be measurable if everyone start to say like that "it's trivial so > what's the problem adding a few instructions although it was duplicated?" > > You already said "LRU isolate effectiveness". It should be done in there, > isolate_lru_pages and we have been. You need another reasons if you want to > add the duplicated work, strongly. isolate_lru_pages is certainly there but you have to enable a trace point for that. Sometimes it is quite useful to get a reasonably good picture even without all the vmscan tracepoints enabled because they can generate quite a lot of output. So if the counter is available I see no reason to exclude it, especially when it can provide a useful information. One of the most frustrating debugging experience is when you are missing some part of the information and have to guess which part is that and patch, rebuild the kernel and hope to reproduce it again in the same/similar way. There are two things about this and other tracepoint patches in general I believe. 1) Is the tracepoint useful? and 2) Do we have to go over extra hops to show tracepoint data? I guess we are in an agreement that the answer for 1 is yes. And regarding 2, all the data we are showing are there or trivially retrieved without touching _any_ hot path. Som of it might be duplicated with other tracepoints but that can be helpful because you do not have all the tracepoints enabled all the time. So unless you see this particular thing as a road block I would rather keep it. > > The inactive counterpart does that for quite some time already. So why > > It couldn't be a reason. If it was duplicated in there, it would be > better to fix it rather than adding more duplciated work to match both > sides. I really do not see this as a bad thing. > > exactly does that matter? Don't take me wrong but isn't this more on a > > nit picking side than necessary? Or do I just misunderstand your > > concenrs? It is not like we are providing a stable user API as the > > My concern is that I don't see what we can get benefit from those > duplicated work. If it doesn't give benefit to us, I don't want to add. > I hope you think another reasonable reasons. > > > tracepoint is clearly implementation specific and not something to be > > used for anything other than debugging. > > My point is we already had things "LRU isolation effectivness". Namely, > isolate_lru_pages. > > > > > > > - nr_rotated pages which tells us that we are hitting referenced > > > > pages which are deactivated. If this is a large part of the > > > > reported nr_deactivated pages then the active list is too small > > > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > > done in get_scan_count. I tend to agree LRU size is helpful for > > > performance analysis because decreased LRU size signals memory shortage > > > then performance drop. > > > > No, I am not really interested in the exact size but rather to allow to > > find whether we are aging the active list too early... > > Could you elaborate it more that how we can get active list early aging > with nr_rotated? If you see too many referenced pages on the active list then they have been used since promoted and that is an indication that they might be reclaimed too early. If you are debugging a performance issue and see this happening then it might be a good indication to look at. Thanks -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759789AbdACRJY (ORCPT ); Tue, 3 Jan 2017 12:09:24 -0500 Received: from mx2.suse.de ([195.135.220.15]:42151 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752861AbdACRJB (ORCPT ); Tue, 3 Jan 2017 12:09:01 -0500 Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint To: Michal Hocko , linux-mm@kvack.org References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML , Michal Hocko From: Vlastimil Babka Message-ID: <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> Date: Tue, 3 Jan 2017 18:08:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-5-mhocko@kernel.org> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/28/2016 04:30 PM, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. It is > useful to know whether the list is file or anonymous as well. Change > the tracepoint to show symbolic names of the lru rather. > > Signed-off-by: Michal Hocko > --- > include/trace/events/vmscan.h | 20 ++++++++++++++------ > mm/vmscan.c | 2 +- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 6af4dae46db2..cc0b4c456c78 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -36,6 +36,14 @@ > (RECLAIM_WB_ASYNC) \ > ) > > +#define show_lru_name(lru) \ > + __print_symbolic(lru, \ > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > + Does this work with external tools such as trace-cmd, i.e. does it export the correct format file? I wouldn't expect it to be that easy to avoid the EM()/EMe() dance :) Also can we make the symbolic names lower_case and without the LRU_ prefix? I think it's more consistent with other mm tracepoints, shorter and nicer. > TRACE_EVENT(mm_vmscan_kswapd_sleep, > > TP_PROTO(int nid), > @@ -277,9 +285,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), > > - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), > + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), > > TP_STRUCT__entry( > __field(int, classzone_idx) > @@ -289,7 +297,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __field(unsigned long, nr_skipped) > __field(unsigned long, nr_taken) > __field(isolate_mode_t, isolate_mode) > - __field(int, file) > + __field(int, lru) > ), > > TP_fast_assign( > @@ -300,10 +308,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_skipped = nr_skipped; > __entry->nr_taken = nr_taken; > __entry->isolate_mode = isolate_mode; > - __entry->file = file; > + __entry->lru = lru; > ), > > - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", > + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", > __entry->isolate_mode, > __entry->classzone_idx, > __entry->order, > @@ -311,7 +319,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __entry->nr_scanned, > __entry->nr_skipped, > __entry->nr_taken, > - __entry->file) > + show_lru_name(__entry->lru)) > ); > > TRACE_EVENT(mm_vmscan_writepage, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 4f7c0d66d629..3f0774f30a42 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > } > *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - skipped, nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, lru); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965226AbdACRWu (ORCPT ); Tue, 3 Jan 2017 12:22:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:42895 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759927AbdACRVv (ORCPT ); Tue, 3 Jan 2017 12:21:51 -0500 Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate To: Michal Hocko , linux-mm@kvack.org References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML , Michal Hocko From: Vlastimil Babka Message-ID: Date: Tue, 3 Jan 2017 18:21:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161228153032.10821-4-mhocko@kernel.org> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/28/2016 04:30 PM, Michal Hocko wrote: > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > unsigned long nr_taken = 0; > unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; > unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; > + unsigned long skipped = 0, total_skipped = 0; > unsigned long scan, nr_pages; > LIST_HEAD(pages_skipped); > > @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > */ > if (!list_empty(&pages_skipped)) { > int zid; > - unsigned long total_skipped = 0; > > for (zid = 0; zid < MAX_NR_ZONES; zid++) { > if (!nr_skipped[zid]) > continue; > > __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); > - total_skipped += nr_skipped[zid]; > + skipped += nr_skipped[zid]; > } > > /* > @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > * close to unreclaimable. If the LRU list is empty, account > * skipped pages as a full scan. > */ > - scan += list_empty(src) ? total_skipped : total_skipped >> 2; > + total_skipped = list_empty(src) ? skipped : skipped >> 2; Should the tracepoint output reflect this halving heuristic or rather report the raw data? Or is each variant inferrable from the other? > > list_splice(&pages_skipped, src); > } > - *nr_scanned = scan; > + *nr_scanned = scan + total_skipped; > trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, > - nr_taken, mode, is_file_lru(lru)); > + skipped, nr_taken, mode, is_file_lru(lru)); > update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); > return nr_taken; > } > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758434AbdACUo7 (ORCPT ); Tue, 3 Jan 2017 15:44:59 -0500 Received: from mx2.suse.de ([195.135.220.15]:53606 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757005AbdACUoz (ORCPT ); Tue, 3 Jan 2017 15:44:55 -0500 Date: Tue, 3 Jan 2017 21:43:33 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML Subject: Re: [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Message-ID: <20170103204331.GB13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-4-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 18:21:48, Vlastimil Babka wrote: > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -1428,6 +1428,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > unsigned long nr_taken = 0; > > unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; > > unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; > > + unsigned long skipped = 0, total_skipped = 0; > > unsigned long scan, nr_pages; > > LIST_HEAD(pages_skipped); > > > > @@ -1479,14 +1480,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > */ > > if (!list_empty(&pages_skipped)) { > > int zid; > > - unsigned long total_skipped = 0; > > > > for (zid = 0; zid < MAX_NR_ZONES; zid++) { > > if (!nr_skipped[zid]) > > continue; > > > > __count_zid_vm_events(PGSCAN_SKIP, zid, nr_skipped[zid]); > > - total_skipped += nr_skipped[zid]; > > + skipped += nr_skipped[zid]; > > } > > > > /* > > @@ -1494,13 +1494,13 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, > > * close to unreclaimable. If the LRU list is empty, account > > * skipped pages as a full scan. > > */ > > - scan += list_empty(src) ? total_skipped : total_skipped >> 2; > > + total_skipped = list_empty(src) ? skipped : skipped >> 2; > > Should the tracepoint output reflect this halving heuristic or rather report > the raw data? Or is each variant inferrable from the other? I would rather see the raw data because you can always go and check the _current_ implementation and calculate the heuristic. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965942AbdACUr5 (ORCPT ); Tue, 3 Jan 2017 15:47:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:53873 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934875AbdACUrt (ORCPT ); Tue, 3 Jan 2017 15:47:49 -0500 Date: Tue, 3 Jan 2017 21:47:45 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103204745.GC13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. It is > > useful to know whether the list is file or anonymous as well. Change > > the tracepoint to show symbolic names of the lru rather. > > > > Signed-off-by: Michal Hocko > > --- > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > mm/vmscan.c | 2 +- > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 6af4dae46db2..cc0b4c456c78 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -36,6 +36,14 @@ > > (RECLAIM_WB_ASYNC) \ > > ) > > > > +#define show_lru_name(lru) \ > > + __print_symbolic(lru, \ > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > + > > Does this work with external tools such as trace-cmd, i.e. does it export > the correct format file? How do I find out? > I wouldn't expect it to be that easy to avoid the EM()/EMe() dance :) Well, I will not pretend I understand the EM dances... > Also can we make the symbolic names lower_case and without the LRU_ prefix? > I think it's more consistent with other mm tracepoints, shorter and nicer. OK, will make it lowercase without the LRU_ prefix. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966012AbdACUxa (ORCPT ); Tue, 3 Jan 2017 15:53:30 -0500 Received: from mx2.suse.de ([195.135.220.15]:54063 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965959AbdACUwy (ORCPT ); Tue, 3 Jan 2017 15:52:54 -0500 Date: Tue, 3 Jan 2017 21:52:44 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103205244.GD13873@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103204745.GC13873@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 21:47:45, Michal Hocko wrote: > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > from is file or anonymous but we do not know which LRU this is. It is > > > useful to know whether the list is file or anonymous as well. Change > > > the tracepoint to show symbolic names of the lru rather. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > > mm/vmscan.c | 2 +- > > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 6af4dae46db2..cc0b4c456c78 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -36,6 +36,14 @@ > > > (RECLAIM_WB_ASYNC) \ > > > ) > > > > > > +#define show_lru_name(lru) \ > > > + __print_symbolic(lru, \ > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > > + > > > > Does this work with external tools such as trace-cmd, i.e. does it export > > the correct format file? > > How do I find out? Well, I've just checked the format file and it says print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) So the tool should be OK as long as it can find values for LRU_* constants. Is this what is the problem? -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759331AbdACVkc (ORCPT ); Tue, 3 Jan 2017 16:40:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:56489 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548AbdACVkZ (ORCPT ); Tue, 3 Jan 2017 16:40:25 -0500 Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint To: Michal Hocko References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> <20170103212411.GA17822@dhcp22.suse.cz> Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML From: Vlastimil Babka Message-ID: Date: Tue, 3 Jan 2017 22:40:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170103212411.GA17822@dhcp22.suse.cz> 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 01/03/2017 10:24 PM, Michal Hocko wrote: > On Tue 03-01-17 21:52:44, Michal Hocko wrote: >> On Tue 03-01-17 21:47:45, Michal Hocko wrote: >> > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: >> > > On 12/28/2016 04:30 PM, Michal Hocko wrote: >> > > > From: Michal Hocko >> > > > >> > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate >> > > > from is file or anonymous but we do not know which LRU this is. It is >> > > > useful to know whether the list is file or anonymous as well. Change >> > > > the tracepoint to show symbolic names of the lru rather. >> > > > >> > > > Signed-off-by: Michal Hocko >> > > > --- >> > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ >> > > > mm/vmscan.c | 2 +- >> > > > 2 files changed, 15 insertions(+), 7 deletions(-) >> > > > >> > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h >> > > > index 6af4dae46db2..cc0b4c456c78 100644 >> > > > --- a/include/trace/events/vmscan.h >> > > > +++ b/include/trace/events/vmscan.h >> > > > @@ -36,6 +36,14 @@ >> > > > (RECLAIM_WB_ASYNC) \ >> > > > ) >> > > > >> > > > +#define show_lru_name(lru) \ >> > > > + __print_symbolic(lru, \ >> > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ >> > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ >> > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ >> > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ >> > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) >> > > > + >> > > >> > > Does this work with external tools such as trace-cmd, i.e. does it export >> > > the correct format file? >> > >> > How do I find out? You did :) Another way to verify is to use trace-cmd tool instead of manual sysfs operations and see if the output looks as expected. The tool gets the raw records from kernel and does the printing in userspace, unlike "cat trace_pipe". >> Well, I've just checked the format file and it says >> print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) >> >> So the tool should be OK as long as it can find values for LRU_* >> constants. Is this what is the problem? Exactly. > OK, I got it. We need enum->value translation and all the EM stuff to do > that, right? Yep. > I will rework the patch and move the definition to the rest of the EM > family... 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 S966429AbdACVtq (ORCPT ); Tue, 3 Jan 2017 16:49:46 -0500 Received: from mx2.suse.de ([195.135.220.15]:56859 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932179AbdACVtY (ORCPT ); Tue, 3 Jan 2017 16:49:24 -0500 Date: Tue, 3 Jan 2017 22:48:54 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103214854.GC18167@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> <20170103212411.GA17822@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 22:40:23, Vlastimil Babka wrote: > On 01/03/2017 10:24 PM, Michal Hocko wrote: [...] > > > So the tool should be OK as long as it can find values for LRU_* > > > constants. Is this what is the problem? > > Exactly. So this should make it work (it compiles it has to be correct, right?). --- diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h index aa4caa6914a9..6172afa2fd82 100644 --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ EMe(ZONE_MOVABLE,"Movable") +#define LRU_NAMES \ + EM (LRU_INACTIVE_ANON, "inactive_anon") \ + EM (LRU_ACTIVE_ANON, "active_anon") \ + EM (LRU_INACTIVE_FILE, "inactive_file") \ + EM (LRU_ACTIVE_FILE, "active_file") \ + EMe(LRU_UNEVICTABLE, "unevictable") + /* * First define the enums in the above macros to be exported to userspace * via TRACE_DEFINE_ENUM(). @@ -253,6 +260,7 @@ COMPACTION_STATUS COMPACTION_PRIORITY COMPACTION_FEEDBACK ZONE_TYPE +LRU_NAMES /* * Now redefine the EM() and EMe() macros to map the enums to the strings diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 8e7c4c56499a..3c38d9315b43 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -36,14 +36,6 @@ (RECLAIM_WB_ASYNC) \ ) -#define show_lru_name(lru) \ - __print_symbolic(lru, \ - {LRU_INACTIVE_ANON, "inactive_anon"}, \ - {LRU_ACTIVE_ANON, "active_anon"}, \ - {LRU_INACTIVE_FILE, "inactive_file"}, \ - {LRU_ACTIVE_FILE, "active_file"}, \ - {LRU_UNEVICTABLE, "unevictable"}) - TRACE_EVENT(mm_vmscan_kswapd_sleep, TP_PROTO(int nid), @@ -319,7 +311,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - show_lru_name(__entry->lru)) + __print_symbolic(__entry->lru, LRU_NAMES)) ); TRACE_EVENT(mm_vmscan_writepage, -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758716AbdACWOm (ORCPT ); Tue, 3 Jan 2017 17:14:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:57971 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757209AbdACWOf (ORCPT ); Tue, 3 Jan 2017 17:14:35 -0500 Date: Tue, 3 Jan 2017 22:24:11 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170103212411.GA17822@dhcp22.suse.cz> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-5-mhocko@kernel.org> <19b44b6e-037f-45fd-a13a-be5d87259e75@suse.cz> <20170103204745.GC13873@dhcp22.suse.cz> <20170103205244.GD13873@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103205244.GD13873@dhcp22.suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 03-01-17 21:52:44, Michal Hocko wrote: > On Tue 03-01-17 21:47:45, Michal Hocko wrote: > > On Tue 03-01-17 18:08:58, Vlastimil Babka wrote: > > > On 12/28/2016 04:30 PM, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > > > from is file or anonymous but we do not know which LRU this is. It is > > > > useful to know whether the list is file or anonymous as well. Change > > > > the tracepoint to show symbolic names of the lru rather. > > > > > > > > Signed-off-by: Michal Hocko > > > > --- > > > > include/trace/events/vmscan.h | 20 ++++++++++++++------ > > > > mm/vmscan.c | 2 +- > > > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > > index 6af4dae46db2..cc0b4c456c78 100644 > > > > --- a/include/trace/events/vmscan.h > > > > +++ b/include/trace/events/vmscan.h > > > > @@ -36,6 +36,14 @@ > > > > (RECLAIM_WB_ASYNC) \ > > > > ) > > > > > > > > +#define show_lru_name(lru) \ > > > > + __print_symbolic(lru, \ > > > > + {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, \ > > > > + {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, \ > > > > + {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, \ > > > > + {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, \ > > > > + {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > > > + > > > > > > Does this work with external tools such as trace-cmd, i.e. does it export > > > the correct format file? > > > > How do I find out? > > Well, I've just checked the format file and it says > print fmt: "isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", REC->isolate_mode, REC->classzone_idx, REC->order, REC->nr_requested, REC->nr_scanned, REC->nr_skipped, REC->nr_taken, __print_symbolic(REC->lru, {LRU_INACTIVE_ANON, "LRU_INACTIVE_ANON"}, {LRU_ACTIVE_ANON, "LRU_ACTIVE_ANON"}, {LRU_INACTIVE_FILE, "LRU_INACTIVE_FILE"}, {LRU_ACTIVE_FILE, "LRU_ACTIVE_FILE"}, {LRU_UNEVICTABLE, "LRU_UNEVICTABLE"}) > > So the tool should be OK as long as it can find values for LRU_* > constants. Is this what is the problem? OK, I got it. We need enum->value translation and all the EM stuff to do that, right? I will rework the patch and move the definition to the rest of the EM family... -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751533AbdADFH1 (ORCPT ); Wed, 4 Jan 2017 00:07:27 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:44464 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbdADFHZ (ORCPT ); Wed, 4 Jan 2017 00:07:25 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Wed, 4 Jan 2017 14:07:22 +0900 From: Minchan Kim To: Michal Hocko Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170104050722.GA17166@bbox> References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103082122.GA30111@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote: > On Tue 03-01-17 14:03:28, Minchan Kim wrote: > > Hi Michal, > > > > On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote: > > > On Sat 31-12-16 01:04:56, Minchan Kim wrote: > > > [...] > > > > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001 > > > > > From: Michal Hocko > > > > > Date: Tue, 27 Dec 2016 13:18:20 +0100 > > > > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint > > > > > > > > > > Our reclaim process has several tracepoints to tell us more about how > > > > > things are progressing. We are, however, missing a tracepoint to track > > > > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports > > > > > > > > I agree this part. > > > > > > > > > the number of > > > > > - nr_scanned, nr_taken pages to tell us the LRU isolation > > > > > effectiveness. > > > > > > > > I agree nr_taken for knowing shrinking effectiveness but don't > > > > agree nr_scanned. If we want to know LRU isolation effectiveness > > > > with nr_scanned and nr_taken, isolate_lru_pages will do. > > > > > > Yes it will. On the other hand the number is there and there is no > > > additional overhead, maintenance or otherwise, to provide that number. > > > > You are adding some instructions, how can you imagine it's no overhead? > > There should be close to zero overhead when the tracepoint is disabled > (we pay only one more argument when the function is called). Is this > really worth discussing in this cold path? We are talking about the > reclaim here. I am talking about that why we should add pointless code in there. No matter it's overhead. We are looping infinite. Blindly, it adds overhead although you might think so trivial. > > > Let's say whether it's measurable. Although it's not big in particular case, > > it would be measurable if everyone start to say like that "it's trivial so > > what's the problem adding a few instructions although it was duplicated?" > > > > You already said "LRU isolate effectiveness". It should be done in there, > > isolate_lru_pages and we have been. You need another reasons if you want to > > add the duplicated work, strongly. > > isolate_lru_pages is certainly there but you have to enable a trace > point for that. Sometimes it is quite useful to get a reasonably good > picture even without all the vmscan tracepoints enabled because they > can generate quite a lot of output. So if the counter is available I If someone want to see "isolate effectivenss", he should enable mm_vmscan_lru_isolate which was born in that and has more helpful information. Think it in an opposit way. If some users want to see just active list aging problem and no interested in "LRU isolate effectivness", you are adding meaningless output for him and he has no choice to turn it off with your patch. > see no reason to exclude it, especially when it can provide a useful > information. One of the most frustrating debugging experience is when I said several times. Please think over if everyone begins adding extra parameters in every tracepoints which we could already get it via other tracepoint with "just, it might be useful in a specific context". Could you be happy with that, really? > you are missing some part of the information and have to guess which > part is that and patch, rebuild the kernel and hope to reproduce it > again in the same/similar way. No need to rebuild. Just enable mm_vmscan_lru_isolate. > > There are two things about this and other tracepoint patches in general > I believe. 1) Is the tracepoint useful? and 2) Do we have to go over > extra hops to show tracepoint data? > > I guess we are in an agreement that the answer for 1 is yes. And yeb. > regarding 2, all the data we are showing are there or trivially > retrieved without touching _any_ hot path. Som of it might be duplicated Currently, you rely on just unfortunate modulization to just add unncessary information to the tracepoint. I just removed nr_scanned in your patch and look below. ./scripts/bloat-o-meter vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 0/6 up/down: 0/-147 (-147) function old new delta perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 shrink_active_list 1265 1232 -33 trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 Total: Before=26268743, After=26268596, chg -0.00% Let's furhter it more. We can factor out logics to account isolation of LRU from shrink_[in]active_list which is more clean, I think. >>From 1053968d526427ecad96b682aa586701c4ecfc84 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Wed, 4 Jan 2017 10:04:36 +0900 Subject: [PATCH] factor out LRU isolation accounting. Not-yet-signed-off-by: Minchan Kim --- include/trace/events/vmscan.h | 14 +++++---- mm/vmscan.c | 68 ++++++++++++++++++------------------------- 2 files changed, 37 insertions(+), 45 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 79b3cd9c7048..5fc3a94a14cd 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -364,14 +364,15 @@ TRACE_EVENT(mm_vmscan_writepage, TRACE_EVENT(mm_vmscan_lru_shrink_inactive, TP_PROTO(int nid, - unsigned long nr_scanned, unsigned long nr_reclaimed, + unsigned long nr_taken, + unsigned long nr_reclaimed, int priority, int file), - TP_ARGS(nid, nr_scanned, nr_reclaimed, priority, file), + TP_ARGS(nid, nr_taken, nr_reclaimed, priority, file), TP_STRUCT__entry( __field(int, nid) - __field(unsigned long, nr_scanned) + __field(unsigned long, nr_taken) __field(unsigned long, nr_reclaimed) __field(int, priority) __field(int, reclaim_flags) @@ -379,15 +380,16 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, TP_fast_assign( __entry->nid = nid; - __entry->nr_scanned = nr_scanned; + __entry->nr_taken = nr_taken; __entry->nr_reclaimed = nr_reclaimed; __entry->priority = priority; __entry->reclaim_flags = trace_shrink_flags(file); ), - TP_printk("nid=%d nr_scanned=%ld nr_reclaimed=%ld priority=%d flags=%s", + TP_printk("nid=%d nr_taken=%ld nr_reclaimed=%ld priority=%d flags=%s", __entry->nid, - __entry->nr_scanned, __entry->nr_reclaimed, + __entry->nr_taken, + __entry->nr_reclaimed, __entry->priority, show_reclaim_flags(__entry->reclaim_flags)) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index 37ccd4e0b349..74f55f39f963 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1454,16 +1454,16 @@ static __always_inline void update_lru_sizes(struct lruvec *lruvec, * @nr_to_scan: The number of pages to look through on the list. * @lruvec: The LRU vector to pull pages from. * @dst: The temp list to put pages on to. - * @nr_scanned: The number of pages that were scanned. * @sc: The scan_control struct for this reclaim session * @mode: One of the LRU isolation modes * @lru: LRU list id for isolating * * returns how many pages were moved onto *@dst. */ -static unsigned long isolate_lru_pages(unsigned long nr_to_scan, +static unsigned long isolate_lru_pages(struct pglist_data *pgdat, + unsigned long nr_to_scan, struct lruvec *lruvec, struct list_head *dst, - unsigned long *nr_scanned, struct scan_control *sc, + struct scan_control *sc, isolate_mode_t mode, enum lru_list lru) { struct list_head *src = &lruvec->lists[lru]; @@ -1471,8 +1471,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, unsigned long nr_zone_taken[MAX_NR_ZONES] = { 0 }; unsigned long nr_skipped[MAX_NR_ZONES] = { 0, }; unsigned long scan, nr_pages; + struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; LIST_HEAD(pages_skipped); + int file = is_file_lru(lru); + spin_lock_irq(&pgdat->lru_lock); for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan && !list_empty(src);) { struct page *page; @@ -1540,10 +1543,25 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, list_splice(&pages_skipped, src); } - *nr_scanned = scan; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, nr_taken, mode, is_file_lru(lru)); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); + + __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken); + reclaim_stat->recent_scanned[file] += nr_taken; + + if (global_reclaim(sc)) + __mod_node_page_state(pgdat, NR_PAGES_SCANNED, scan); + if (is_active_lru(lru)) { + __count_vm_events(PGREFILL, scan); + } else { + if (current_is_kswapd()) + __count_vm_events(PGSCAN_KSWAPD, scan); + else + __count_vm_events(PGSCAN_DIRECT, scan); + } + spin_unlock_irq(&pgdat->lru_lock); + return nr_taken; } @@ -1735,7 +1753,6 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, struct scan_control *sc, enum lru_list lru) { LIST_HEAD(page_list); - unsigned long nr_scanned; unsigned long nr_reclaimed = 0; unsigned long nr_taken; unsigned long nr_dirty = 0; @@ -1746,7 +1763,6 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); - struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; if (!inactive_reclaimable_pages(lruvec, sc, lru)) return 0; @@ -1766,23 +1782,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, if (!sc->may_writepage) isolate_mode |= ISOLATE_CLEAN; - spin_lock_irq(&pgdat->lru_lock); - - nr_taken = isolate_lru_pages(nr_to_scan, lruvec, &page_list, - &nr_scanned, sc, isolate_mode, lru); - - __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken); - reclaim_stat->recent_scanned[file] += nr_taken; - - if (global_reclaim(sc)) { - __mod_node_page_state(pgdat, NR_PAGES_SCANNED, nr_scanned); - if (current_is_kswapd()) - __count_vm_events(PGSCAN_KSWAPD, nr_scanned); - else - __count_vm_events(PGSCAN_DIRECT, nr_scanned); - } - spin_unlock_irq(&pgdat->lru_lock); - + nr_taken = isolate_lru_pages(pgdat, nr_to_scan, lruvec, &page_list, + sc, isolate_mode, lru); if (nr_taken == 0) return 0; @@ -1866,7 +1867,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, wait_iff_congested(pgdat, BLK_RW_ASYNC, HZ/10); trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id, - nr_scanned, nr_reclaimed, + nr_taken, + nr_reclaimed, sc->priority, file); return nr_reclaimed; } @@ -1943,18 +1945,17 @@ static void shrink_active_list(unsigned long nr_to_scan, enum lru_list lru) { unsigned long nr_taken; - unsigned long nr_scanned; unsigned long vm_flags; LIST_HEAD(l_hold); /* The pages which were snipped off */ LIST_HEAD(l_active); LIST_HEAD(l_inactive); struct page *page; - struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; unsigned nr_deactivate, nr_activate; unsigned nr_rotated = 0; isolate_mode_t isolate_mode = 0; int file = is_file_lru(lru); struct pglist_data *pgdat = lruvec_pgdat(lruvec); + struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; lru_add_drain(); @@ -1963,19 +1964,8 @@ static void shrink_active_list(unsigned long nr_to_scan, if (!sc->may_writepage) isolate_mode |= ISOLATE_CLEAN; - spin_lock_irq(&pgdat->lru_lock); - - nr_taken = isolate_lru_pages(nr_to_scan, lruvec, &l_hold, - &nr_scanned, sc, isolate_mode, lru); - - __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken); - reclaim_stat->recent_scanned[file] += nr_taken; - - if (global_reclaim(sc)) - __mod_node_page_state(pgdat, NR_PAGES_SCANNED, nr_scanned); - __count_vm_events(PGREFILL, nr_scanned); - - spin_unlock_irq(&pgdat->lru_lock); + nr_taken = isolate_lru_pages(pgdat, nr_to_scan, lruvec, &l_hold, + sc, isolate_mode, lru); while (!list_empty(&l_hold)) { cond_resched(); -- 2.7.4 With this, ./scripts/bloat-o-meter vmlinux.old vmlinux.new.new add/remove: 1/1 grow/shrink: 0/9 up/down: 1394/-1636 (-242) function old new delta isolate_lru_pages - 1394 +1394 print_fmt_mm_vmscan_lru_shrink_inactive 359 355 -4 vermagic 64 58 -6 perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 shrink_inactive_list 1430 1271 -159 shrink_active_list 1265 1082 -183 isolate_lru_pages.isra 1170 - -1170 Total: Before=26268743, After=26268501, chg -0.00% We can save 242 bytes. If we consider binary size, 424 bytes save. #> ls -l vmlinux.old vmlinux.new.new 194092840 vmlinux.old 194092416 vmlinux.new.new > with other tracepoints but that can be helpful because you do not have > all the tracepoints enabled all the time. So unless you see this > particular thing as a road block I would rather keep it. I didn't know how long this thread becomes lenghy. To me, it was no worth to discuss. I did best effot to explain my stand with valid points, I think and don't want to go infinite loop. If you don't agree still, separate the patch. One includes only necessary things with removing nr_scanned, which I am happy to ack it. Based upon it, add one more patch you want adding nr_scanned with your claim. I will reply that thread with my claim and let's keep an eye on it that whether maintainer will take it or not. If maintainer will take it, it's good indication which will represent we can add more extra tracepoint easily with "might be helpful with someone although it's redunant" so do not prevent others who want to do in the future. > > > > The inactive counterpart does that for quite some time already. So why > > > > It couldn't be a reason. If it was duplicated in there, it would be > > better to fix it rather than adding more duplciated work to match both > > sides. > > I really do not see this as a bad thing. > > > > exactly does that matter? Don't take me wrong but isn't this more on a > > > nit picking side than necessary? Or do I just misunderstand your > > > concenrs? It is not like we are providing a stable user API as the > > > > My concern is that I don't see what we can get benefit from those > > duplicated work. If it doesn't give benefit to us, I don't want to add. > > I hope you think another reasonable reasons. > > > > > tracepoint is clearly implementation specific and not something to be > > > used for anything other than debugging. > > > > My point is we already had things "LRU isolation effectivness". Namely, > > isolate_lru_pages. > > > > > > > > > > - nr_rotated pages which tells us that we are hitting referenced > > > > > pages which are deactivated. If this is a large part of the > > > > > reported nr_deactivated pages then the active list is too small > > > > > > > > It might be but not exactly. If your goal is to know LRU size, it can be > > > > done in get_scan_count. I tend to agree LRU size is helpful for > > > > performance analysis because decreased LRU size signals memory shortage > > > > then performance drop. > > > > > > No, I am not really interested in the exact size but rather to allow to > > > find whether we are aging the active list too early... > > > > Could you elaborate it more that how we can get active list early aging > > with nr_rotated? > > If you see too many referenced pages on the active list then they have > been used since promoted and that is an indication that they might be > reclaimed too early. If you are debugging a performance issue and see > this happening then it might be a good indication to look at. This is better than "active list is too small". I hope you change description with this. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964999AbdADH2s (ORCPT ); Wed, 4 Jan 2017 02:28:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:47447 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934593AbdADH2r (ORCPT ); Wed, 4 Jan 2017 02:28:47 -0500 Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint To: Minchan Kim , Michal Hocko References: <20161228153032.10821-1-mhocko@kernel.org> <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> <20170104050722.GA17166@bbox> Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Rik van Riel , LKML From: Vlastimil Babka Message-ID: <9f77c4d2-dddf-8fc6-0982-edf02a58b15f@suse.cz> Date: Wed, 4 Jan 2017 08:28:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170104050722.GA17166@bbox> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/04/2017 06:07 AM, Minchan Kim wrote: > With this, > ./scripts/bloat-o-meter vmlinux.old vmlinux.new.new > add/remove: 1/1 grow/shrink: 0/9 up/down: 1394/-1636 (-242) > function old new delta > isolate_lru_pages - 1394 +1394 > print_fmt_mm_vmscan_lru_shrink_inactive 359 355 -4 > vermagic 64 58 -6 > perf_trace_mm_vmscan_lru_shrink_active 264 256 -8 > trace_raw_output_mm_vmscan_lru_shrink_active 203 193 -10 > trace_event_raw_event_mm_vmscan_lru_shrink_active 241 225 -16 > print_fmt_mm_vmscan_lru_shrink_active 458 426 -32 > trace_event_define_fields_mm_vmscan_lru_shrink_active 384 336 -48 > shrink_inactive_list 1430 1271 -159 > shrink_active_list 1265 1082 -183 > isolate_lru_pages.isra 1170 - -1170 > Total: Before=26268743, After=26268501, chg -0.00% > > We can save 242 bytes. > > If we consider binary size, 424 bytes save. > > #> ls -l vmlinux.old vmlinux.new.new > 194092840 vmlinux.old > 194092416 vmlinux.new.new Which is roughly 0.0002%. Not that I'm against fighting bloat, but let's not forget that it's not the only factor. For example the following part from above: > isolate_lru_pages - 1394 +1394 > isolate_lru_pages.isra 1170 - -1170 shows that your change has prevented a -fipa-src gcc optimisation, which is "interprocedural scalar replacement of aggregates, removal of unused parameters and replacement of parameters passed by reference by parameters passed by value." Well, I'm no gcc expert :) but it might be that the change is not a simple win-win. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757455AbdADHvG (ORCPT ); Wed, 4 Jan 2017 02:51:06 -0500 Received: from mx2.suse.de ([195.135.220.15]:48261 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757218AbdADHvD (ORCPT ); Wed, 4 Jan 2017 02:51:03 -0500 Date: Wed, 4 Jan 2017 08:50:58 +0100 From: Michal Hocko To: Minchan Kim Cc: Hillf Danton , linux-mm@kvack.org, Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Rik van Riel , LKML Subject: Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint Message-ID: <20170104075058.GA25453@dhcp22.suse.cz> References: <20161228153032.10821-3-mhocko@kernel.org> <20161229053359.GA1815@bbox> <20161229075243.GA29208@dhcp22.suse.cz> <20161230014853.GA4184@bbox> <20161230092636.GA13301@dhcp22.suse.cz> <20161230160456.GA7267@bbox> <20161230163742.GK13301@dhcp22.suse.cz> <20170103050328.GA15700@bbox> <20170103082122.GA30111@dhcp22.suse.cz> <20170104050722.GA17166@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104050722.GA17166@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 04-01-17 14:07:22, Minchan Kim wrote: > On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote: [...] > > with other tracepoints but that can be helpful because you do not have > > all the tracepoints enabled all the time. So unless you see this > > particular thing as a road block I would rather keep it. > > I didn't know how long this thread becomes lenghy. To me, it was no worth > to discuss. I did best effot to explain my stand with valid points, I think > and don't want to go infinite loop. If you don't agree still, separate > the patch. One includes only necessary things with removing nr_scanned, which > I am happy to ack it. Based upon it, add one more patch you want adding > nr_scanned with your claim. I will reply that thread with my claim and > let's keep an eye on it that whether maintainer will take it or not. To be honest this is just not worth the effort and rather than discussing further I will just drop the nr_scanned slthough I disagree that your concerns regarding this _particular counter_ are really valid. > If maintainer will take it, it's good indication which will represent > we can add more extra tracepoint easily with "might be helpful with someone > although it's redunant" so do not prevent others who want to do > in the future. no we do not work in a precedence system like that. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936213AbdADKVt (ORCPT ); Wed, 4 Jan 2017 05:21:49 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36230 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759586AbdADKUH (ORCPT ); Wed, 4 Jan 2017 05:20:07 -0500 From: Michal Hocko To: Andrew Morton Cc: Mel Gorman , Johannes Weiner , Vlastimil Babka , Minchan Kim , Hillf Danton , , LKML , Michal Hocko Subject: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Wed, 4 Jan 2017 11:19:39 +0100 Message-Id: <20170104101942.4860-5-mhocko@kernel.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170104101942.4860-1-mhocko@kernel.org> References: <20170104101942.4860-1-mhocko@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Hocko mm_vmscan_lru_isolate currently prints only whether the LRU we isolate from is file or anonymous but we do not know which LRU this is. It is useful to know whether the list is active or inactive, since we are using the same function to isolate pages from both of them and it's hard to distinguish otherwise. Chaneges since v1 - drop LRU_ prefix from names and use lowercase as per Vlastimil - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil Acked-by: Hillf Danton Acked-by: Mel Gorman Signed-off-by: Michal Hocko --- include/trace/events/mmflags.h | 8 ++++++++ include/trace/events/vmscan.h | 12 ++++++------ mm/vmscan.c | 2 +- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h index aa4caa6914a9..6172afa2fd82 100644 --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ EMe(ZONE_MOVABLE,"Movable") +#define LRU_NAMES \ + EM (LRU_INACTIVE_ANON, "inactive_anon") \ + EM (LRU_ACTIVE_ANON, "active_anon") \ + EM (LRU_INACTIVE_FILE, "inactive_file") \ + EM (LRU_ACTIVE_FILE, "active_file") \ + EMe(LRU_UNEVICTABLE, "unevictable") + /* * First define the enums in the above macros to be exported to userspace * via TRACE_DEFINE_ENUM(). @@ -253,6 +260,7 @@ COMPACTION_STATUS COMPACTION_PRIORITY COMPACTION_FEEDBACK ZONE_TYPE +LRU_NAMES /* * Now redefine the EM() and EMe() macros to map the enums to the strings diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index 36c999f806bf..7ec59e0432c4 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, unsigned long nr_skipped, unsigned long nr_taken, isolate_mode_t isolate_mode, - int file), + int lru), - TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, file), + TP_ARGS(classzone_idx, order, nr_requested, nr_scanned, nr_skipped, nr_taken, isolate_mode, lru), TP_STRUCT__entry( __field(int, classzone_idx) @@ -289,7 +289,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __field(unsigned long, nr_skipped) __field(unsigned long, nr_taken) __field(isolate_mode_t, isolate_mode) - __field(int, file) + __field(int, lru) ), TP_fast_assign( @@ -300,10 +300,10 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_skipped = nr_skipped; __entry->nr_taken = nr_taken; __entry->isolate_mode = isolate_mode; - __entry->file = file; + __entry->lru = lru; ), - TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu file=%d", + TP_printk("isolate_mode=%d classzone=%d order=%d nr_requested=%lu nr_scanned=%lu nr_skipped=%lu nr_taken=%lu lru=%s", __entry->isolate_mode, __entry->classzone_idx, __entry->order, @@ -311,7 +311,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, __entry->nr_scanned, __entry->nr_skipped, __entry->nr_taken, - __entry->file) + __print_symbolic(__entry->lru, LRU_NAMES)) ); TRACE_EVENT(mm_vmscan_writepage, diff --git a/mm/vmscan.c b/mm/vmscan.c index 31c623d5acb4..13758aaed78b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1500,7 +1500,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, } *nr_scanned = scan + total_skipped; trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scan, - skipped, nr_taken, mode, is_file_lru(lru)); + skipped, nr_taken, mode, lru); update_lru_sizes(lruvec, lru, nr_zone_taken, nr_taken); return nr_taken; } -- 2.11.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032495AbdAEGF7 (ORCPT ); Thu, 5 Jan 2017 01:05:59 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:57049 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032415AbdAEGFH (ORCPT ); Thu, 5 Jan 2017 01:05:07 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 5 Jan 2017 15:04:58 +0900 From: Minchan Kim To: Michal Hocko Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105060458.GC24371@bbox> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104101942.4860-5-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 04, 2017 at 11:19:39AM +0100, Michal Hocko wrote: > From: Michal Hocko > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > from is file or anonymous but we do not know which LRU this is. > > It is useful to know whether the list is active or inactive, since we > are using the same function to isolate pages from both of them and it's > hard to distinguish otherwise. > > Chaneges since v1 > - drop LRU_ prefix from names and use lowercase as per Vlastimil > - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil > > Acked-by: Hillf Danton > Acked-by: Mel Gorman > Signed-off-by: Michal Hocko > --- > include/trace/events/mmflags.h | 8 ++++++++ > include/trace/events/vmscan.h | 12 ++++++------ > mm/vmscan.c | 2 +- > 3 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > index aa4caa6914a9..6172afa2fd82 100644 > --- a/include/trace/events/mmflags.h > +++ b/include/trace/events/mmflags.h > @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ > EMe(ZONE_MOVABLE,"Movable") > > +#define LRU_NAMES \ > + EM (LRU_INACTIVE_ANON, "inactive_anon") \ > + EM (LRU_ACTIVE_ANON, "active_anon") \ > + EM (LRU_INACTIVE_FILE, "inactive_file") \ > + EM (LRU_ACTIVE_FILE, "active_file") \ > + EMe(LRU_UNEVICTABLE, "unevictable") > + > /* > * First define the enums in the above macros to be exported to userspace > * via TRACE_DEFINE_ENUM(). > @@ -253,6 +260,7 @@ COMPACTION_STATUS > COMPACTION_PRIORITY > COMPACTION_FEEDBACK > ZONE_TYPE > +LRU_NAMES > > /* > * Now redefine the EM() and EMe() macros to map the enums to the strings > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index 36c999f806bf..7ec59e0432c4 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > unsigned long nr_skipped, > unsigned long nr_taken, > isolate_mode_t isolate_mode, > - int file), > + int lru), It may break trace-vmscan-postprocess.pl. Other than that, Acked-by: 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 S938379AbdAEKRj (ORCPT ); Thu, 5 Jan 2017 05:17:39 -0500 Received: from mx2.suse.de ([195.135.220.15]:58453 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938366AbdAEKQQ (ORCPT ); Thu, 5 Jan 2017 05:16:16 -0500 Date: Thu, 5 Jan 2017 11:16:13 +0100 From: Michal Hocko To: Minchan Kim , Mel Gorman Cc: Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105101613.GG21618@dhcp22.suse.cz> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170105060458.GC24371@bbox> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 05-01-17 15:04:58, Minchan Kim wrote: > On Wed, Jan 04, 2017 at 11:19:39AM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate > > from is file or anonymous but we do not know which LRU this is. > > > > It is useful to know whether the list is active or inactive, since we > > are using the same function to isolate pages from both of them and it's > > hard to distinguish otherwise. > > > > Chaneges since v1 > > - drop LRU_ prefix from names and use lowercase as per Vlastimil > > - move and convert show_lru_name to mmflags.h EM magic as per Vlastimil > > > > Acked-by: Hillf Danton > > Acked-by: Mel Gorman > > Signed-off-by: Michal Hocko > > > --- > > include/trace/events/mmflags.h | 8 ++++++++ > > include/trace/events/vmscan.h | 12 ++++++------ > > mm/vmscan.c | 2 +- > > 3 files changed, 15 insertions(+), 7 deletions(-) > > > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > > index aa4caa6914a9..6172afa2fd82 100644 > > --- a/include/trace/events/mmflags.h > > +++ b/include/trace/events/mmflags.h > > @@ -240,6 +240,13 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > > IFDEF_ZONE_HIGHMEM( EM (ZONE_HIGHMEM,"HighMem")) \ > > EMe(ZONE_MOVABLE,"Movable") > > > > +#define LRU_NAMES \ > > + EM (LRU_INACTIVE_ANON, "inactive_anon") \ > > + EM (LRU_ACTIVE_ANON, "active_anon") \ > > + EM (LRU_INACTIVE_FILE, "inactive_file") \ > > + EM (LRU_ACTIVE_FILE, "active_file") \ > > + EMe(LRU_UNEVICTABLE, "unevictable") > > + > > /* > > * First define the enums in the above macros to be exported to userspace > > * via TRACE_DEFINE_ENUM(). > > @@ -253,6 +260,7 @@ COMPACTION_STATUS > > COMPACTION_PRIORITY > > COMPACTION_FEEDBACK > > ZONE_TYPE > > +LRU_NAMES > > > > /* > > * Now redefine the EM() and EMe() macros to map the enums to the strings > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > index 36c999f806bf..7ec59e0432c4 100644 > > --- a/include/trace/events/vmscan.h > > +++ b/include/trace/events/vmscan.h > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > unsigned long nr_skipped, > > unsigned long nr_taken, > > isolate_mode_t isolate_mode, > > - int file), > > + int lru), > > It may break trace-vmscan-postprocess.pl. Other than that, I wasn't aware of the script. And you are right it will break it. The following should fix it. Btw. shrink_inactive_list tracepoint changes will to be synced as well. I do not speak perl much but the following should just work (untested yet). --- diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 8f961ef2b457..ba976805853a 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -112,8 +112,8 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; -my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)'; -my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)'; +my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -205,15 +205,15 @@ $regex_wakeup_kswapd = generate_traceevent_regex( $regex_lru_isolate = generate_traceevent_regex( "vmscan/mm_vmscan_lru_isolate", $regex_lru_isolate_default, - "isolate_mode", "order", - "nr_requested", "nr_scanned", "nr_taken", - "file"); + "isolate_mode", "classzone_idx", "order", + "nr_requested", "nr_scanned", "nr_skipped", "nr_taken", + "lru"); $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, - "nid", "zid", - "nr_scanned", "nr_reclaimed", "priority", - "flags"); + "nid", "nr_scanned", "nr_reclaimed", "nr_dirty", "nr_writeback", + "nr_congested", "nr_immediate", "nr_activate", "nr_ref_keep", + "nr_unmap_fail", "priority", "flags"); $regex_lru_shrink_active = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_active", $regex_lru_shrink_active_default, @@ -381,8 +381,8 @@ sub process_events { next; } my $isolate_mode = $1; - my $nr_scanned = $4; - my $file = $6; + my $nr_scanned = $5; + my $file = $8; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -391,7 +391,7 @@ sub process_events { # isolate_both == 3 if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; - if ($file == 1) { + if ($file =~ /_file/) { $perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned; } else { $perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned; @@ -406,8 +406,8 @@ sub process_events { next; } - my $nr_reclaimed = $4; - my $flags = $6; + my $nr_reclaimed = $3; + my $flags = $12; my $file = 0; if ($flags =~ /RECLAIM_WB_FILE/) { $file = 1; > Acked-by: Minchan Kim Thanks -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S970946AbdAEO4i (ORCPT ); Thu, 5 Jan 2017 09:56:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:48222 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967852AbdAEO41 (ORCPT ); Thu, 5 Jan 2017 09:56:27 -0500 Date: Thu, 5 Jan 2017 14:56:23 +0000 From: Mel Gorman To: Michal Hocko Cc: Minchan Kim , Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105145623.h7jbgke2ij5opsvz@suse.de> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> <20170105101613.GG21618@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170105101613.GG21618@dhcp22.suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 05, 2017 at 11:16:13AM +0100, Michal Hocko wrote: > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > index 36c999f806bf..7ec59e0432c4 100644 > > > --- a/include/trace/events/vmscan.h > > > +++ b/include/trace/events/vmscan.h > > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > > unsigned long nr_skipped, > > > unsigned long nr_taken, > > > isolate_mode_t isolate_mode, > > > - int file), > > > + int lru), > > > > It may break trace-vmscan-postprocess.pl. Other than that, > > I wasn't aware of the script. And you are right it will break it. The > following should fix it. Btw. shrink_inactive_list tracepoint changes > will to be synced as well. I do not speak perl much but the following > should just work (untested yet). It's also optional to remove them. When those were first merged, it was done to illustrate how multiple tracepoints can be used to aggregate tracepoint information. They are better ways of gathering the same class of information. They are of historical interest but not as fully supported scripts that can never break. -- Mel Gorman SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034187AbdAEPSs (ORCPT ); Thu, 5 Jan 2017 10:18:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:49845 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751607AbdAEPSU (ORCPT ); Thu, 5 Jan 2017 10:18:20 -0500 Date: Thu, 5 Jan 2017 16:17:37 +0100 From: Michal Hocko To: Mel Gorman Cc: Minchan Kim , Andrew Morton , Johannes Weiner , Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Message-ID: <20170105151737.GU21618@dhcp22.suse.cz> References: <20170104101942.4860-1-mhocko@kernel.org> <20170104101942.4860-5-mhocko@kernel.org> <20170105060458.GC24371@bbox> <20170105101613.GG21618@dhcp22.suse.cz> <20170105145623.h7jbgke2ij5opsvz@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170105145623.h7jbgke2ij5opsvz@suse.de> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 05-01-17 14:56:23, Mel Gorman wrote: > On Thu, Jan 05, 2017 at 11:16:13AM +0100, Michal Hocko wrote: > > > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > > > > index 36c999f806bf..7ec59e0432c4 100644 > > > > --- a/include/trace/events/vmscan.h > > > > +++ b/include/trace/events/vmscan.h > > > > @@ -277,9 +277,9 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > > > > unsigned long nr_skipped, > > > > unsigned long nr_taken, > > > > isolate_mode_t isolate_mode, > > > > - int file), > > > > + int lru), > > > > > > It may break trace-vmscan-postprocess.pl. Other than that, > > > > I wasn't aware of the script. And you are right it will break it. The > > following should fix it. Btw. shrink_inactive_list tracepoint changes > > will to be synced as well. I do not speak perl much but the following > > should just work (untested yet). > > It's also optional to remove them. When those were first merged, it was > done to illustrate how multiple tracepoints can be used to aggregate > tracepoint information. They are better ways of gathering the same class > of information. They are of historical interest but not as fully supported > scripts that can never break. Yeah, that was my understanding and why I didn't consider it a priority. But it seemed like an easy thing to fix even with my anti-perl mindset. Here is the full patch (untested) --- >>From 1b843a180a1436873aab1fe3819dfc7dbf393870 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 5 Jan 2017 11:34:03 +0100 Subject: [PATCH] trace-vmscan-postprocess: sync with tracepoints updates Both mm_vmscan_lru_shrink_active and mm_vmscan_lru_isolate have changed so the script needs to be update to reflect those changes Signed-off-by: Michal Hocko --- .../trace/postprocess/trace-vmscan-postprocess.pl | 26 +++++++++++----------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 8f961ef2b457..ba976805853a 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -112,8 +112,8 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; -my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)'; -my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)'; +my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -205,15 +205,15 @@ $regex_wakeup_kswapd = generate_traceevent_regex( $regex_lru_isolate = generate_traceevent_regex( "vmscan/mm_vmscan_lru_isolate", $regex_lru_isolate_default, - "isolate_mode", "order", - "nr_requested", "nr_scanned", "nr_taken", - "file"); + "isolate_mode", "classzone_idx", "order", + "nr_requested", "nr_scanned", "nr_skipped", "nr_taken", + "lru"); $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, - "nid", "zid", - "nr_scanned", "nr_reclaimed", "priority", - "flags"); + "nid", "nr_scanned", "nr_reclaimed", "nr_dirty", "nr_writeback", + "nr_congested", "nr_immediate", "nr_activate", "nr_ref_keep", + "nr_unmap_fail", "priority", "flags"); $regex_lru_shrink_active = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_active", $regex_lru_shrink_active_default, @@ -381,8 +381,8 @@ sub process_events { next; } my $isolate_mode = $1; - my $nr_scanned = $4; - my $file = $6; + my $nr_scanned = $5; + my $file = $8; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -391,7 +391,7 @@ sub process_events { # isolate_both == 3 if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; - if ($file == 1) { + if ($file =~ /_file/) { $perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned; } else { $perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned; @@ -406,8 +406,8 @@ sub process_events { next; } - my $nr_reclaimed = $4; - my $flags = $6; + my $nr_reclaimed = $3; + my $flags = $12; my $file = 0; if ($flags =~ /RECLAIM_WB_FILE/) { $file = 1; -- 2.11.0 -- Michal Hocko SUSE Labs