Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755646Ab0GaJnJ (ORCPT ); Sat, 31 Jul 2010 05:43:09 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1]:52724 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755534Ab0GaJnH (ORCPT ); Sat, 31 Jul 2010 05:43:07 -0400 Message-ID: <4C53F01A.8090205@cs.helsinki.fi> Date: Sat, 31 Jul 2010 12:42:50 +0300 From: Pekka Enberg User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Catalin Marinas CC: Daniel J Blueman , Linux Kernel Subject: Re: [2.6.35-rc6 patch] increase kmemleak robustness at boot References: <4C505F86.7050509@cs.helsinki.fi> <4C519A6E.8000002@cs.helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 908 Lines: 20 Catalin Marinas wrote: >> Right. I guess the required earlylog buffer size would be smaller if >> we initialized kmemleak earlier. Can we do that in mm_init() after >> kmem_cache_init()? > > Kmemleak uses kmem_cache_alloc() internally so we could initialise it > as soon as kmem_cache_init() was called. But it's really strange the > amount of early allocations that Daniel is getting. I've been happy so > far with 400, usually with standard Ubuntu-like configs and some > debugging turned on. Any idea what's causing these allocations? No idea. I wonder if kmemleak can dump out the call-sites for the overflow case somehow to see what's going on? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/