From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id 1800B6B002B for ; Wed, 17 Oct 2012 15:45:12 -0400 (EDT) Date: Wed, 17 Oct 2012 15:45:01 -0400 From: Dave Jones Subject: Re: [patch for-3.7] mm, mempolicy: fix printing stack contents in numa_maps Message-ID: <20121017194501.GA24400@redhat.com> References: <20121017040515.GA13505@redhat.com> <20121017181413.GA16805@redhat.com> <20121017193229.GC16805@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Andrew Morton , Linus Torvalds , KOSAKI Motohiro , bhutchings@solarflare.com, Konstantin Khlebnikov , Naoya Horiguchi , Hugh Dickins , KAMEZAWA Hiroyuki , linux-kernel@vger.kernel.org, linux-mm@kvack.org On Wed, Oct 17, 2012 at 12:38:55PM -0700, David Rientjes wrote: > > > 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? > > > > Killing the fuzzer caused it to drop dramatically. > > > Excellent, thanks. This shows that the refcounting is working properly > and we're not leaking any references as a result of this change causing > the mempolicies to never be freed. ("numa_policy" turns out to be > policy_cache in the code, so thanks for checking both of them.) > > Could I add your tested-by? Sure. Here's a fresh one I just baked. Tested-by: Dave Jones Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org