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 S1751207AbbCSUS1 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 19 Mar 2015 16:18:27 -0400
Received: from mailout1.w1.samsung.com ([210.118.77.11]:50537 "EHLO
	mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750731AbbCSUSY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 19 Mar 2015 16:18:24 -0400
X-AuditID: cbfec7f5-b7fc86d0000066b7-b2-550b2e76b232
Message-id: <550B2F0A.3010909@partner.samsung.com>
Date: Thu, 19 Mar 2015 23:18:18 +0300
From: Stefan Strogin <s.strogin@partner.samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.5.0
MIME-version: 1.0
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Michal Nazarewicz <mina86@mina86.com>, aneesh.kumar@linux.vnet.ibm.com,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Dmitry Safonov <d.safonov@partner.samsung.com>,
        Pintu Kumar <pintu.k@samsung.com>,
        Weijie Yang <weijie.yang@samsung.com>,
        Laura Abbott <lauraa@codeaurora.org>,
        SeongJae Park <sj38.park@gmail.com>, Hui Zhu <zhuhui@xiaomi.com>,
        Minchan Kim <minchan@kernel.org>, Dyasly Sergey <s.dyasly@samsung.com>,
        Vyacheslav Tyrtov <v.tyrtov@samsung.com>,
        Aleksei Mateosian <a.mateosian@samsung.com>, gregory.0xf0@gmail.com,
        sasha.levin@oracle.com, gioh.kim@lge.com, pavel@ucw.cz,
        stefan.strogin@gmail.com, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v4 1/5] mm: cma: add trace events to debug
 physically-contiguous memory allocations
References: <cover.1426521377.git.s.strogin@partner.samsung.com>
 <a1127b32325d3c527636912eefd6892bd8fc746d.1426521377.git.s.strogin@partner.samsung.com>
 <550741BD.9080109@partner.samsung.com>
 <20150316194750.04885ee7@grimm.local.home>
In-reply-to: <20150316194750.04885ee7@grimm.local.home>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRiA/c45O+dsa3C8xaeU0SjUSlMR+ogIoYKDFPhHjOy2dKjlUdly
	pP4xHaYbrfKScxNZpJX3dRy0UsSWeSUxtQLFYZm3bJqaN4zM037Uv+d9eXjePy+New0S/nRK
	2k2lKk2RKiclRP/v7pEQTag0Nozf3I8+VxVTqLK5gUST81UEWq6dItF03k+AHpZbRahWn0+i
	F0VGChU9qKbQ8KtKEjkbtkWosXOcQpZurQg9WV2k0FCHBUPjfW9JZFh/Q6H2wgkMlZj90Vpv
	JY4ed47h6KP9HoaGv29TqMy4QaFe6zsRsuZLovzZYcNdjH1pGqdYbfsoxZoLK0QsX1dEsvxy
	McXqXCMY22PcItgJRwvBNv36hrFLU6ME+3qhDWMX2z+QrMFWB9hn9esUu8IHxHhekJxIVKam
	aJSqoyevSpJdXQNERrX0VkXrHTwXFIh1QExDJhLaN8dFbt4NB53NpA5IaC+mBsCOjgWRe1gC
	0GArBoIlYyLgV3M9LjDBHISNA08xgcmdUtdg+Y5D077MeTg2LHbrnnCjxEkI7MMEQa1lhhCa
	OPOJhMaVgr9NbyYFLnYs4e5jPwC8bXJgQkjMHIPOsgwBcSYQlpZygo4z+2BLgwu/DxjTfydM
	/yzTf5YF4HXAV5mZkKG+lsRFhKoVnDozLSk0IZ3jgfsLVu2gpuu4AzA0kO+SeUBprJdIoVFn
	cQ4AaVzuI+ODd1ayREVWtlKVfkWVmapUOwBGi/1zAd+K9/jaRmVHzp6RRprzCmO0tWttpZdy
	bixfd2kP67ef91w+l1+yJyZ7tib6ol94vNTM2bigsH4/wwEuOWdSkReln9M4UkcfzZ46rezX
	DwSjLd5hj2Oi3hcFxM8wumDPL019ummP+b3r/EZInM9QUuDMnMlWbI62eqOJICgn1MmK8EO4
	Sq34A+ITbGzjAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 17/03/15 02:47, Steven Rostedt wrote:
>>> +TRACE_EVENT(cma_alloc,
>>> +
>>> +	TP_PROTO(struct cma *cma, struct page *page, int count),
>>> +
>>> +	TP_ARGS(cma, page, count),
>>> +
>>> +	TP_STRUCT__entry(
>>> +		__field(struct page *, page)
>>> +		__field(unsigned long, count)
>>> +	),
>>> +
>>> +	TP_fast_assign(
>>> +		__entry->page = page;
>>> +		__entry->count = count;
>>> +	),
>>> +
>>> +	TP_printk("page=%p pfn=%lu count=%lu",
>>> +		  __entry->page,
>>> +		  __entry->page ? page_to_pfn(__entry->page) : 0,
> 
> Can page_to_pfn(value) ever be different throughout the life of the
> boot? That is, can it return a different result given the same value
> (vmalloc area comes to mind).
> 
>>> +	TP_printk("pfn=%lu page=%p count=%lu",
>>> +		  __entry->pfn,
>>> +		  pfn_to_page(__entry->pfn),
> 
> Same here. Can pfn_to_page(value) ever return a different result with
> the same value in a single boot?
> 

Thank you for the reply, Steven.
I supposed that page_to_pfn() cannot change after mem_map
initialization, can it? I'm not sure about such things as memory hotplug
though...
Also cma_alloc() calls alloc_contig_range() which returns pfn, then it's
converted to struct page * and cma_alloc() returns struct page *, and
vice versa in cma_release() (receives struct page * and passes pfn to
free_contig_rage()).
Do you mean that printing pfn (or struct page *) in trace event is
redundant?