From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by kanga.kvack.org (Postfix) with ESMTP id 250C88E0001 for ; Thu, 13 Sep 2018 04:40:14 -0400 (EDT) Received: by mail-ed1-f72.google.com with SMTP id z56-v6so2121373edz.10 for ; Thu, 13 Sep 2018 01:40:14 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id c22-v6si3076996edt.291.2018.09.13.01.40.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 01:40:12 -0700 (PDT) Date: Thu, 13 Sep 2018 10:40:11 +0200 From: Michal Hocko Subject: Re: [PATCH V2 0/6] VA to numa node information Message-ID: <20180913084011.GC20287@dhcp22.suse.cz> References: <1536783844-4145-1-git-send-email-prakash.sangappa@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1536783844-4145-1-git-send-email-prakash.sangappa@oracle.com> Sender: owner-linux-mm@kvack.org List-ID: To: Prakash Sangappa Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, dave.hansen@intel.com, nao.horiguchi@gmail.com, akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, khandual@linux.vnet.ibm.com, steven.sistare@oracle.com On Wed 12-09-18 13:23:58, Prakash Sangappa wrote: > For analysis purpose it is useful to have numa node information > corresponding mapped virtual address ranges of a process. Currently, > the file /proc//numa_maps provides list of numa nodes from where pages > are allocated per VMA of a process. This is not useful if an user needs to > determine which numa node the mapped pages are allocated from for a > particular address range. It would have helped if the numa node information > presented in /proc//numa_maps was broken down by VA ranges showing the > exact numa node from where the pages have been allocated. > > The format of /proc//numa_maps file content is dependent on > /proc//maps file content as mentioned in the manpage. i.e one line > entry for every VMA corresponding to entries in /proc//maps file. > Therefore changing the output of /proc//numa_maps may not be possible. > > This patch set introduces the file /proc//numa_vamaps which > will provide proper break down of VA ranges by numa node id from where the > mapped pages are allocated. For Address ranges not having any pages mapped, > a '-' is printed instead of numa node id. > > Includes support to lseek, allowing seeking to a specific process Virtual > address(VA) starting from where the address range to numa node information > can to be read from this file. > > The new file /proc//numa_vamaps will be governed by ptrace access > mode PTRACE_MODE_READ_REALCREDS. > > See following for previous discussion about this proposal > > https://marc.info/?t=152524073400001&r=1&w=2 It would be really great to give a short summary of the previous discussion. E.g. why do we need a proc interface in the first place when we already have an API to query for the information you are proposing to export [1] [1] http://lkml.kernel.org/r/20180503085741.GD4535@dhcp22.suse.cz -- Michal Hocko SUSE Labs