From: Ingo Molnar <mingo@elte.hu>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Stefani Seibold <stefani@seibold.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [patch 2/2] procfs: provide stack information for threads V0.10
Date: Wed, 24 Jun 2009 19:46:37 +0200 [thread overview]
Message-ID: <20090624174637.GA7576@elte.hu> (raw)
In-Reply-To: <20090624174025.GA13170@cmpxchg.org>
* Johannes Weiner <hannes@cmpxchg.org> wrote:
> On Wed, Jun 24, 2009 at 05:49:50PM +0200, Stefani Seibold wrote:
> > Am Mittwoch, den 24.06.2009, 17:20 +0200 schrieb Ingo Molnar:
> > > * Stefani Seibold <stefani@seibold.net> wrote:
> > >
> > > > Hi,
> > > >
> > > > this is the newest version of the formaly named "detailed stack info"
> > > > patch which give you a better overview of the userland application stack
> > > > usage, especially for embedded linux.
> > > >
> > > > Currently you are only able to dump the main process/thread stack usage
> > > > which is showed in /proc/pid/status by the "VmStk" Value. But you get no
> > > > information about the consumed stack memory of the the threads.
> > > >
> > > > There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which
> > > > marks the vm mapping where the thread stack pointer reside with "[thread
> > > > stack xxxxxxxx]". xxxxxxxx is the maximum size of stack. This is a
> > > > value information, because libpthread doesn't set the start of the stack
> > > > to the top of the mapped area, depending of the pthread usage.
> > > >
> > > > A sample output of /proc/<pid>/task/<tid>/maps looks like:
> > > >
> > > > 08048000-08049000 r-xp 00000000 03:00 8312 /opt/z
> > > > 08049000-0804a000 rw-p 00001000 03:00 8312 /opt/z
> > > > 0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
> > > > a7d12000-a7d13000 ---p 00000000 00:00 0
> > > > a7d13000-a7f13000 rw-p 00000000 00:00 0 [thread stack: 001ff4b4]
> > >
> > > I have the same question as before: have you checked the use of that
> > > field in tools/perf/builtin-record.c, and how your change will
> > > impact that?
> > >
> >
> > Good question... i have another one: What is
> > tools/perf/builtin-record.c and where can i find it? Then i
> > could check it.
>
> You can find it in a recent git tree from Linus.
>
> On the original question: builtin-record.c is unaffected by this
> patch as this exact field will only be parsed if the mapping is
> executable.
A stack can be executable too. It is not common, but possible.
Ingo
next prev parent reply other threads:[~2009-06-24 17:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906182243.n5IMhwuV003008@imap1.linux-foundation.org>
[not found] ` <1245824444.22613.3.camel@wall-e>
[not found] ` <20090623233247.7ed661b7.akpm@linux-foundation.org>
2009-06-24 6:45 ` [merged] proctxt-update-kernel-filesystem-proctxt-documentation.patch removed from -mm tree Stefani Seibold
2009-06-24 7:13 ` Andrew Morton
2009-06-24 7:35 ` Eric W. Biederman
2009-06-24 9:33 ` Stefani Seibold
2009-06-24 15:30 ` Andrew Morton
2009-06-24 15:57 ` Stefani Seibold
2009-06-24 12:03 ` [patch 2/2] procfs: provide stack information for threads V0.9 Stefani Seibold
2009-06-24 14:33 ` [patch 2/2] procfs: provide stack information for threads V0.10 Stefani Seibold
2009-06-24 15:20 ` Ingo Molnar
2009-06-24 15:49 ` Stefani Seibold
2009-06-24 17:40 ` Johannes Weiner
2009-06-24 17:46 ` Ingo Molnar [this message]
2009-06-24 19:08 ` Johannes Weiner
2009-06-25 9:36 ` Ingo Molnar
2009-06-25 10:09 ` [tip:perfcounters/urgent] perf record: Fix filemap pathname parsing in /proc/pid/maps tip-bot for Johannes Weiner
2009-06-24 16:28 ` [patch 2/2] procfs: provide stack information for threads V0.11 Stefani Seibold
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=20090624174637.GA7576@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefani@seibold.net \
/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