[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1210171219010.28214@chino.kir.corp.google.com>
Date: Wed, 17 Oct 2012 12:21:10 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Dave Jones <davej@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@...il.com>,
bhutchings@...arflare.com,
Konstantin Khlebnikov <khlebnikov@...nvz.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Hugh Dickins <hughd@...gle.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch for-3.7] mm, mempolicy: fix printing stack contents in
numa_maps
On Wed, 17 Oct 2012, Dave Jones wrote:
> On Tue, Oct 16, 2012 at 10:24:32PM -0700, David Rientjes wrote:
> > On Wed, 17 Oct 2012, Dave Jones wrote:
> >
> > > BUG: sleeping function called from invalid context at kernel/mutex.c:269
> >
> > Hmm, looks like we need to change the refcount semantics entirely. We'll
> > need to make get_vma_policy() always take a reference and then drop it
> > accordingly. This work sif get_vma_policy() can grab a reference while
> > holding task_lock() for the task policy fallback case.
> >
> > Comments on this approach?
>
> Seems to be surviving my testing at least..
>
Sounds good. Is it possible to verify that policy_cache isn't getting
larger than normal in /proc/slabinfo, i.e. when all processes with a
task mempolicy or shared vma policy have exited, are there still a
significant number of active objects?
--
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