From: Michal Hocko <mhocko@kernel.org> To: Minchan Kim <minchan@kernel.org> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@redhat.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Fri, 30 Dec 2016 10:33:10 +0100 [thread overview] Message-ID: <20161230093308.GB13301@dhcp22.suse.cz> (raw) In-Reply-To: <20161230015625.GB4184@bbox> 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 <mhocko@suse.com> > > > > > > > > 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 <mhocko@suse.com> > > > > > > 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Minchan Kim <minchan@kernel.org> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Vlastimil Babka <vbabka@suse.cz>, Rik van Riel <riel@redhat.com>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Date: Fri, 30 Dec 2016 10:33:10 +0100 [thread overview] Message-ID: <20161230093308.GB13301@dhcp22.suse.cz> (raw) In-Reply-To: <20161230015625.GB4184@bbox> 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 <mhocko@suse.com> > > > > > > > > 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 <mhocko@suse.com> > > > > > > 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-12-30 9:33 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-28 15:30 [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-28 15:30 ` [PATCH 1/7] mm, vmscan: remove unused mm_vmscan_memcg_isolate Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 7:33 ` Hillf Danton 2016-12-29 7:33 ` Hillf Danton 2016-12-28 15:30 ` [PATCH 2/7] mm, vmscan: add active list aging tracepoint Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 5:33 ` Minchan Kim 2016-12-29 5:33 ` Minchan Kim 2016-12-29 7:52 ` Michal Hocko 2016-12-29 7:52 ` Michal Hocko 2016-12-30 1:48 ` Minchan Kim 2016-12-30 1:48 ` Minchan Kim 2016-12-30 9:26 ` Michal Hocko 2016-12-30 9:26 ` Michal Hocko 2016-12-30 9:38 ` Hillf Danton 2016-12-30 9:38 ` Hillf Danton 2016-12-30 16:04 ` Minchan Kim 2016-12-30 16:04 ` Minchan Kim 2016-12-30 16:37 ` Michal Hocko 2016-12-30 16:37 ` Michal Hocko 2016-12-30 17:30 ` Michal Hocko 2016-12-30 17:30 ` Michal Hocko 2017-01-03 5:03 ` Minchan Kim 2017-01-03 5:03 ` Minchan Kim 2017-01-03 8:21 ` Michal Hocko 2017-01-03 8:21 ` Michal Hocko 2017-01-04 5:07 ` Minchan Kim 2017-01-04 5:07 ` Minchan Kim 2017-01-04 7:28 ` Vlastimil Babka 2017-01-04 7:28 ` Vlastimil Babka 2017-01-04 7:50 ` Michal Hocko 2017-01-04 7:50 ` Michal Hocko 2016-12-29 7:44 ` Hillf Danton 2016-12-29 7:44 ` Hillf Danton 2016-12-28 15:30 ` [PATCH 3/7] mm, vmscan: show the number of skipped pages in mm_vmscan_lru_isolate Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 5:53 ` Minchan Kim 2016-12-29 5:53 ` Minchan Kim 2016-12-29 7:49 ` Hillf Danton 2016-12-29 7:49 ` Hillf Danton 2017-01-03 17:21 ` Vlastimil Babka 2017-01-03 17:21 ` Vlastimil Babka 2017-01-03 20:43 ` Michal Hocko 2017-01-03 20:43 ` Michal Hocko 2016-12-28 15:30 ` [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-28 15:50 ` Nikolay Borisov 2016-12-28 15:50 ` Nikolay Borisov 2016-12-28 16:00 ` Michal Hocko 2016-12-28 16:00 ` Michal Hocko 2016-12-28 16:40 ` Nikolay Borisov 2016-12-28 16:40 ` Nikolay Borisov 2016-12-28 16:49 ` Michal Hocko 2016-12-28 16:49 ` Michal Hocko 2016-12-29 6:02 ` Minchan Kim 2016-12-29 6:02 ` Minchan Kim 2016-12-29 7:56 ` Michal Hocko 2016-12-29 7:56 ` Michal Hocko 2016-12-30 1:56 ` Minchan Kim 2016-12-30 1:56 ` Minchan Kim 2016-12-30 9:33 ` Michal Hocko [this message] 2016-12-30 9:33 ` Michal Hocko 2016-12-29 7:53 ` Hillf Danton 2016-12-29 7:53 ` Hillf Danton 2017-01-03 17:08 ` Vlastimil Babka 2017-01-03 17:08 ` Vlastimil Babka 2017-01-03 20:47 ` Michal Hocko 2017-01-03 20:47 ` Michal Hocko 2017-01-03 20:52 ` Michal Hocko 2017-01-03 20:52 ` Michal Hocko 2017-01-03 21:24 ` Michal Hocko 2017-01-03 21:24 ` Michal Hocko 2017-01-03 21:40 ` Vlastimil Babka 2017-01-03 21:40 ` Vlastimil Babka 2017-01-03 21:48 ` Michal Hocko 2017-01-03 21:48 ` Michal Hocko 2016-12-28 15:30 ` [PATCH 5/7] mm, vmscan: extract shrink_page_list reclaim counters into a struct Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 8:00 ` Hillf Danton 2016-12-29 8:00 ` Hillf Danton 2016-12-28 15:30 ` [PATCH 6/7] mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 8:05 ` Hillf Danton 2016-12-29 8:05 ` Hillf Danton 2016-12-28 15:30 ` [PATCH 7/7] mm, vmscan: add mm_vmscan_inactive_list_is_low tracepoint Michal Hocko 2016-12-28 15:30 ` Michal Hocko 2016-12-29 8:19 ` Hillf Danton 2016-12-29 8:19 ` Hillf Danton 2016-12-30 9:11 ` [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints Mel Gorman 2016-12-30 9:11 ` Mel Gorman 2016-12-30 9:36 ` Michal Hocko 2016-12-30 9:36 ` Michal Hocko 2016-12-30 10:20 ` Mel Gorman 2016-12-30 10:20 ` Mel Gorman 2017-01-04 10:19 [PATCH 0/7 v2] " Michal Hocko 2017-01-04 10:19 ` [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint Michal Hocko 2017-01-04 10:19 ` Michal Hocko 2017-01-05 6:04 ` Minchan Kim 2017-01-05 6:04 ` Minchan Kim 2017-01-05 10:16 ` Michal Hocko 2017-01-05 10:16 ` Michal Hocko 2017-01-05 14:56 ` Mel Gorman 2017-01-05 14:56 ` Mel Gorman 2017-01-05 15:17 ` Michal Hocko 2017-01-05 15:17 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20161230093308.GB13301@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=minchan@kernel.org \ --cc=riel@redhat.com \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.