From: Michal Hocko <mhocko@kernel.org>
To: "prakash.sangappa" <prakash.sangappa@oracle.com>
Cc: Steven Sistare <steven.sistare@oracle.com>,
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
Subject: Re: [PATCH V2 0/6] VA to numa node information
Date: Wed, 19 Dec 2018 21:52:15 +0100 [thread overview]
Message-ID: <20181219205215.GC5689@dhcp22.suse.cz> (raw)
In-Reply-To: <c81d912f-157f-749a-92fb-78f5e836da85@oracle.com>
On Tue 18-12-18 15:46:45, prakash.sangappa wrote:
[...]
> Dave Hansen asked how would it scale, with respect reading this file from
> a large process. Answer is, the file contents are generated using page
> table walk, and copied to user buffer. The mmap_sem lock is drop and
> re-acquired in the process of walking the page table and copying file
> content. The kernel buffer size used determines how long the lock is held.
> Which can be further improved to drop the lock and re-acquire after a
> fixed number(512) of pages are walked.
I guess you are still missing the point here. Have you tried a larger
mapping with interleaved memory policy? I would bet my hat that you are
going to spend a large part of the time just pushing the output to the
userspace... Not to mention the parsing on the consumer side.
Also you keep failing (IMO) explaining _who_ is going to be the consumer
of the file. What kind of analysis will need such an optimized data
collection and what can you do about that?
This is really _essential_ when adding a new interface to provide a data
that is already available by other means. In other words tell us your
specific usecase that is hitting a bottleneck that cannot be handled by
the existing API and we can start considering a new one.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2018-12-19 20:52 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
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 [this message]
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=20181219205215.GC5689@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=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=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).