From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753191AbbCPIfa (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Mar 2015 04:35:30 -0400
Received: from mail-la0-f45.google.com ([209.85.215.45]:34910 "EHLO
	mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753118AbbCPIf0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Mar 2015 04:35:26 -0400
MIME-Version: 1.0
In-Reply-To: <20150316082642.GA19478@gmail.com>
References: <1426145571-3065-1-git-send-email-namhyung@kernel.org>
 <20150312104119.GA5978@gmail.com> <20150312145837.GA1398@danjae>
 <20150316021035.GQ943@sejong> <20150316082642.GA19478@gmail.com>
From: Namhyung Kim <namhyung@kernel.org>
Date: Mon, 16 Mar 2015 17:35:04 +0900
X-Google-Sender-Auth: eVTByXbR0n-7BkIoNX3vWlaUoN0
Message-ID: <CAM9d7ch=yrF5ej3=ukNZCouq3ddbJ+QNZoeABH+Tm=Lqg0buhw@mail.gmail.com>
Subject: Re: [RFC/PATCHSET 0/6] perf kmem: Implement page allocation analysis (v1)
To: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>, Jiri Olsa <jolsa@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, David Ahern <dsahern@gmail.com>,
        Minchan Kim <minchan@kernel.org>, Joonsoo Kim <js1304@gmail.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Ingo,

On Mon, Mar 16, 2015 at 5:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Namhyung Kim <namhyung@kernel.org> wrote:
>
>> On Thu, Mar 12, 2015 at 11:58:37PM +0900, Namhyung Kim wrote:
>> > On Thu, Mar 12, 2015 at 11:41:19AM +0100, Ingo Molnar wrote:
>> > > So there's one thing that would be useful: to track pages allocated on
>> > > one node, but freed on another. Those kinds of allocation/free
>> > > patterns are especially expensive and might make sense to visualize.
>> >
>> > I think it can be done easily as slab analysis already contains the info.
>>
>> Hmm.. it seems slab events provide the node info but page events
>> don't.  Without it, I don't know which node a page is in so cannot
>> determine such cross-node alloc+free patterns.
>
> Well, but we know the CPU that the allocation occured on, and can map
> the CPU to the node.

Does it gaurantee that the page always belongs to a same node
allocating cpu is in?  I can simply map the page with an node using
cpu info but was not sure whether that's always correct.


Thanks,
Namhyung