[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090616213004.GA6687@x200.localdomain>
Date: Wed, 17 Jun 2009 01:30:04 +0400
From: Alexey Dobriyan <adobriyan@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Stefani Seibold <stefani@...bold.net>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl, mingo@...e.hu
Subject: Re: + procfs-provide-stack-information-for-threads-v08.patch added
to -mm tree
On Tue, Jun 16, 2009 at 12:39:28PM -0700, Eric W. Biederman wrote:
> Stefani Seibold <stefani@...bold.net> writes:
>
> > Am Dienstag, den 16.06.2009, 02:33 +0400 schrieb Alexey Dobriyan:
> >> On Mon, Jun 15, 2009 at 03:02:05PM -0700, akpm@...ux-foundation.org wrote:
> >> > procfs-provide-stack-information-for-threads-v08.patch
> >> > --- a/fs/proc/array.c~procfs-provide-stack-information-for-threads-v08
> >>
> >> > +++ a/fs/proc/array.c
> >> > @@ -321,6 +321,54 @@ static inline void task_context_switch_c
> >> > p->nivcsw);
> >> > }
> >> >
> >> > +static inline unsigned long get_stack_usage_in_bytes(struct vm_area_struct *vma,
> >> > + struct task_struct *p)
> >> > +{
> >> > + unsigned long i;
> >> > + struct page *page;
> >> > + unsigned long stkpage;
> >> > +
> >> > + stkpage = KSTK_ESP(p) & PAGE_MASK;
> >> > +
> >> > +#ifdef CONFIG_STACK_GROWSUP
> >> > + for (i = vma->vm_end; i-PAGE_SIZE > stkpage; i -= PAGE_SIZE) {
> >> > +
> >> > + page = follow_page(vma, i-PAGE_SIZE, 0);
> >>
> >> How can this work?
> >>
> >> If stack page got swapped out, you'll get smaller than actual result.
> >>
> >
> > If you tell me how to do it in the right way, i can fix it!
>
> You are attempting to answer two questions here.
> 1) Where do the thread stacks reside.
Kernel doesn't know. Application stack is somewhere below/above
some SP register.
> 2) What is the maximum stack space that has been used.
>
> Just listing the thread stacks seems like a small O(1) change.
>
> Computing how much stack space has been used looks trickier.
> Perhaps you could map them with MAP_GROWSDOWN? Of course that
> has the problem that you don't stop growing your stack until
> it bumps into something else. Not ideal for a thread stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists