From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751889AbbCTKqr (ORCPT ); Fri, 20 Mar 2015 06:46:47 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:8880 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbbCTKqo (ORCPT ); Fri, 20 Mar 2015 06:46:44 -0400 X-AuditID: cbfec7f5-b7fc86d0000066b7-84-550bf9ea874d Message-id: <550BFA8F.9050803@partner.samsung.com> Date: Fri, 20 Mar 2015 13:46:39 +0300 From: Stefan Strogin 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 Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , Andrew Morton , Marek Szyprowski , Michal Nazarewicz , aneesh.kumar@linux.vnet.ibm.com, Laurent Pinchart , Dmitry Safonov , Pintu Kumar , Weijie Yang , Laura Abbott , SeongJae Park , Hui Zhu , Minchan Kim , Dyasly Sergey , Vyacheslav Tyrtov , Aleksei Mateosian , gregory.0xf0@gmail.com, sasha.levin@oracle.com, gioh.kim@lge.com, pavel@ucw.cz, stefan.strogin@gmail.com, Ingo Molnar Subject: Re: [PATCH v4 1/5] mm: cma: add trace events to debug physically-contiguous memory allocations References: <550741BD.9080109@partner.samsung.com> <20150316194750.04885ee7@grimm.local.home> <550B2F0A.3010909@partner.samsung.com> <20150319163406.4050cdaf@gandalf.local.home> In-reply-to: <20150319163406.4050cdaf@gandalf.local.home> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0jTYRjG+f7nzRb/La2PQRZGpYGHJPDrQBR58dFVGEoHsKYuXbkpm7Os izQtPJCaxzkPjErLU8o0DyGi8zQzQ5smaZohVp7xOKXQnAZ597zv+3ue5+blSEkvJeUUqgi5 WiULdWKEVNd6R5/r5Jqdr0drpgR9L0hjUV5FGYPGpgootFA8zqAfj5YAysqupFFxUiyDahN0 LEp49pJFlnd5DBop26BReeswiwwdcTQqWp5j0acmA4GG37cxKNnawqLG+FECpedK0UpnHole tA6R6HNdCoEs0xssytStsqizsptGlbHCc1JsSX5K4Hr9MIvjGgdZnBufQ2NjSQKDjQtpLE6c 6SOwWfebwqOmKgq/+TNJ4PnxQQo3zzYQeK6xn8HJ1SUAvy61snjR6HhJfE14JkgeqoiUq93P 3hSGjHXPMuE5/L2U51/IaJAkSgQCDvInYH5SD72t98KekQomEQg5CV8IYGl3wb9hHsCG9VrG Rol4Tzg5ZdxyUPxhaK4vIGya2Uxq78kGiYDjHPgrcMgi2MbFcDV9hLJpe94Zxhl+UrZMkh9g oG7xCbAd9vAKONc0T26XmQm4stKy5RDwJ+HEdBtlCyX5ozAjQ2lbk/wBWFU2Q6YCXr+jQ/+f 0u+gDIAsAQ5ybWC4JiBY6emmkSk1WlWwW2CY0gi232C5DhS2nzIBngNOu0TmDjtfCS2L1EQp TQBypJO96Nfc5koUJIu6L1eH3VBrQ+UaEyA4gTQaSO1f5fnHqKJ6U+ia6+IL5112xwQovJXR zJHMrA/hX2+X5Hup71zVqVqL1rrvvp2oCDP1V4+mTB7MfeBhcO+IcGleypbUL9Jm6DzmUHbx 47eHp+2NNY6HHX1Sy/1cJ1QZl/v11kKfrv59/uGHFqSubdrHw1XW/d7Qy/2Ws9+Ao9iJ0oTI jh8j1RrZX5GxvPrkAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/03/15 23:34, Steven Rostedt wrote: > On Thu, 19 Mar 2015 23:18:18 +0300 > Stefan Strogin wrote: > >> 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? > > I'm concerned about the time TP_printk() is executed and when > TP_fast_assign() is. That is, when the tracepoint is called, > TP_fast_assign() is executed, but TP_printk() is called when someone > reads the trace files, which can happen seconds, hours, days, weeks, > months later. > > As long as the result of page_to_pfn() and pfn_to_page() stay the same > throughout the life of the boot, things will be fine. But if they could > ever change, due to hotplug memory or whatever. The data in the trace > buffer will become stale, and report the wrong information. > > -- Steve > Ah, thanks, I see. So will this solve the described issue? + TP_fast_assign( + __entry->page = page; + __entry->pfn = page_to_pfn(__entry->page) : 0; /* or -1 as Ingo suggested */ + __entry->count = count; + ), + + TP_printk("page=%p pfn=%lu count=%u", + __entry->page, + __entry->pfn, + __entry->count) Should we do the same in trace/events/kmem.h then? But really I'm not sure why page_to_pfn()/pfn_to_page() can return different results... I thought that there can appear new 'struct page' entries arrays throughout one boot due to memory hotplug or smth. But how can existing 'struct page' entries associated with the same physical pages change their physical addresses? Or how can one physical address correspond to different physical page throughout one boot?