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 Content-Length: 3069 Lines: 67 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