From: Andrew Morton <akpm@linux-foundation.org>
To: prakash.sangappa@oracle.com
Cc: Michal Hocko <mhocko@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
dave.hansen@intel.com, nao.horiguchi@gmail.com,
kirill.shutemov@linux.intel.com, khandual@linux.vnet.ibm.com,
steven.sistare@oracle.com
Subject: Re: [PATCH V2 0/6] VA to numa node information
Date: Thu, 13 Sep 2018 17:10:16 -0700 [thread overview]
Message-ID: <20180913171016.55dca2453c0773fc21044972@linux-foundation.org> (raw)
In-Reply-To: <375951d0-f103-dec3-34d8-bbeb2f45f666@oracle.com>
On Thu, 13 Sep 2018 15:32:25 -0700 "prakash.sangappa" <prakash.sangappa@oracle.com> wrote:
> >> 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
>
> The proc interface provides an efficient way to export address range
> to numa node id mapping information compared to using the API.
> For example, for sparsely populated mappings, if a VMA has large portions
> not have any physical pages mapped, the page walk done thru the /proc file
> interface can skip over non existent PMDs / ptes. Whereas using the
> API the application would have to scan the entire VMA in page size units.
>
> Also, VMAs having THP pages can have a mix of 4k pages and hugepages.
> The page walks would be efficient in scanning and determining if it is
> a THP huge page and step over it. Whereas using the API, the application
> would not know what page size mapping is used for a given VA and so would
> have to again scan the VMA in units of 4k page size.
>
> If this sounds reasonable, I can add it to the commit / patch description.
Preferably with some runtime measurements, please. How much faster is
this interface in real-world situations? And why does that performance
matter?
It would also be useful to see more details on how this info helps
operators understand/tune/etc their applications and workloads. In
other words, I'm trying to get an understanding of how useful this code
might be to our users in general.
next prev parent reply other threads:[~2018-09-14 0:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 20:23 [PATCH V2 0/6] VA to numa node information Prakash Sangappa
2018-09-12 20:23 ` [PATCH V2 1/6] Add check to match numa node id when gathering pte stats Prakash Sangappa
2018-09-12 20:24 ` [PATCH V2 2/6] Add /proc/<pid>/numa_vamaps file for numa node information Prakash Sangappa
2018-09-12 20:24 ` [PATCH V2 3/6] Provide process address range to numa node id mapping Prakash Sangappa
2018-09-12 20:24 ` [PATCH V2 4/6] Add support to lseek /proc/<pid>/numa_vamaps file Prakash Sangappa
2018-09-12 20:24 ` [PATCH V2 5/6] File /proc/<pid>/numa_vamaps access needs PTRACE_MODE_READ_REALCREDS check Prakash Sangappa
2018-09-12 20:24 ` [PATCH V2 6/6] /proc/pid/numa_vamaps: document in Documentation/filesystems/proc.txt Prakash Sangappa
2018-09-13 8:40 ` [PATCH V2 0/6] VA to numa node information Michal Hocko
2018-09-13 22:32 ` prakash.sangappa
2018-09-14 0:10 ` Andrew Morton [this message]
2018-09-14 0:25 ` Dave Hansen
2018-09-15 1:31 ` Prakash Sangappa
2018-09-14 5:56 ` Michal Hocko
2018-09-14 16:01 ` Steven Sistare
2018-09-14 18:04 ` Prakash Sangappa
2018-09-14 19:01 ` Dave Hansen
2018-09-24 17:14 ` Michal Hocko
2018-11-10 4:48 ` Prakash Sangappa
2018-11-26 19:20 ` Steven Sistare
2018-12-18 23:46 ` prakash.sangappa
2018-12-19 20:52 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180913171016.55dca2453c0773fc21044972@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=nao.horiguchi@gmail.com \
--cc=prakash.sangappa@oracle.com \
--cc=steven.sistare@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).