[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090624083032.2d250488.akpm@linux-foundation.org>
Date: Wed, 24 Jun 2009 08:30:32 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Stefani Seibold <stefani@...bold.net>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Alexey Dobriyan <adobriyan@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [merged]
proctxt-update-kernel-filesystem-proctxt-documentation.patch removed from
-mm tree
On Wed, 24 Jun 2009 11:33:25 +0200 Stefani Seibold <stefani@...bold.net> wrote:
> > > Alexey's point is that follow_page() will return NULL if it hits a
> > > swapped-out stack page and the loop will exit, leading to an incorrect
> > > (ie: short) return value from get_stack_usage_in_bytes().
> > >
> > > Is this claim wrong?
> >
>
> No.
>
> I digged in the kernel source and the only solution i found is to use
> the walk_page_range() like show_smap() in proc/fs/task_mmu.c.
>
> Maybe there is an easier way, but i dont know.
>
> So i would implement a similar function like smaps_pte_range() in
> proc/fs/task_mmu.c to detected the high water usage.
Perhaps we could enhance follow_page() so that it can tell the caller
when the target page is "virtually there", but swapped out. Add a new
FOLL_SWAP, I guess.
How to communicate this back to the caller? Perhaps add another
argument to follow_page(), perhaps return some magic value such as
#define FOLLOW_PAGE_SWAPPED_PAGE ((struct page *)1)
Adding the additional argument would be nicer.
--
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