Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752353AbbLJDhI (ORCPT ); Wed, 9 Dec 2015 22:37:08 -0500 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.231]:59718 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752020AbbLJDhG (ORCPT ); Wed, 9 Dec 2015 22:37:06 -0500 Date: Wed, 9 Dec 2015 22:36:48 -0500 From: Steven Rostedt To: Joonsoo Kim Cc: Vlastimil Babka , Andrew Morton , Michal Nazarewicz , Minchan Kim , Mel Gorman , "Kirill A. Shutemov" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation Message-ID: <20151209223648.4e9122b5@grimm.local.home> In-Reply-To: <20151210025015.GA17967@js1304-P5Q-DELUXE> References: <1447053784-27811-1-git-send-email-iamjoonsoo.kim@lge.com> <1447053784-27811-2-git-send-email-iamjoonsoo.kim@lge.com> <564C9A86.1090906@suse.cz> <20151120063325.GB13061@js1304-P5Q-DELUXE> <20151120114225.7efeeafe@grimm.local.home> <20151123082805.GB29397@js1304-P5Q-DELUXE> <20151123092604.7ec1397d@gandalf.local.home> <20151124014527.GA32335@js1304-P5Q-DELUXE> <20151203041657.GB1495@js1304-P5Q-DELUXE> <20151209150154.31c142b9@gandalf.local.home> <20151210025015.GA17967@js1304-P5Q-DELUXE> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1188 Lines: 31 On Thu, 10 Dec 2015 11:50:15 +0900 Joonsoo Kim wrote: > Output of cpu 3, 7 are mixed and it's not easy to analyze it. > > I think that it'd be better not to sort stack trace. How do > you think about it? Could you fix it, please? It may not be that easy to fix because of the sorting algorithm. That would require looking going ahead one more event each time and then checking if its a stacktrace. I may look at it and see if I can come up with something that's not too invasive in the algorithms. That said, for now you can use the --cpu option. I'm not sure I ever documented it as it was originally added for debugging, but I use it enough that it may be worth while to officially support it. trace-cmd report --cpu 3 Will show you just cpu 3 and nothing else. Which is what I use a lot. But doing the stack trace thing may be something to fix as well. I'll see what I can do, but no guarantees. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/