From: Alexey Dobriyan <adobriyan@gmail.com>
To: Joel Savitz <jsavitz@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Ram Pai <linuxram@us.ibm.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Huang Ying <ying.huang@intel.com>,
Sandeep Patil <sspatil@android.com>,
Rafael Aquini <aquini@redhat.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] fs/proc: add VmTaskSize field to /proc/$$/status
Date: Sun, 28 Apr 2019 00:45:22 +0300 [thread overview]
Message-ID: <20190427214522.GA7074@avx2> (raw)
In-Reply-To: <1556305328-2001-1-git-send-email-jsavitz@redhat.com>
On Fri, Apr 26, 2019 at 03:02:08PM -0400, Joel Savitz wrote:
> In the mainline kernel, there is no quick mechanism to get the virtual
> memory size of the current process from userspace.
>
> Despite the current state of affairs, this information is available to the
> user through several means, one being a linear search of the entire address
> space. This is an inefficient use of cpu cycles.
You can test only a few known per arch values. Linear search is a self
inflicted wound.
prctl(2) is more natural place and will also be arch neutral.
> A component of the libhugetlb kernel test does exactly this, and as
> systems' address spaces increase beyond 32-bits, this method becomes
> exceedingly tedious.
> For example, on a ppc64le system with a 47-bit address space, the linear
> search causes the test to hang for some unknown amount of time. I
> couldn't give you an exact number because I just ran it for about 10-20
> minutes and went to go do something else, probably to get coffee or
> something, and when I came back, I just killed the test and patched it
> to use this new mechanism. I re-ran my new version of the test using a
> kernel with this patch, and of course it passed through the previously
> bottlenecking codepath nearly instantaneously.
>
> This patched enabled me to upgrade an O(n) codepath to O(1) in an
> architecture-independent manner.
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -74,7 +74,10 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> seq_put_decimal_ull_width(m,
> " kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
> SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> - seq_puts(m, " kB\n");
> + SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> + seq_put_decimal_ull_width(m,
> + " kB\nVmTaskSize:\t", TASK_SIZE >> 10, 8);
> + seq_puts(m, " kB\n");
All fields in this file are related to the task. New field related
to "current" will stick like an eyesore.
next prev parent reply other threads:[~2019-04-27 21:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 19:02 [PATCH v2] fs/proc: add VmTaskSize field to /proc/$$/status Joel Savitz
2019-04-27 1:16 ` Rafael Aquini
2019-04-27 21:45 ` Alexey Dobriyan [this message]
2019-04-30 21:01 ` Joel Savitz
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=20190427214522.GA7074@avx2 \
--to=adobriyan@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=aquini@redhat.com \
--cc=jsavitz@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=sspatil@android.com \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.