Re: + procfs-provide-stack-information-for-threads-v08.patch added to -mm tree

[Alexey Dobriyan <adobriyan@gmail.com>]

On Tue, Jun 16, 2009 at 12:39:28PM -0700, Eric W. Biederman wrote:
> Stefani Seibold <stefani@seibold.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@linux-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.