Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965076AbWHQOpJ (ORCPT ); Thu, 17 Aug 2006 10:45:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965067AbWHQOpI (ORCPT ); Thu, 17 Aug 2006 10:45:08 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]:43895 "EHLO nz-out-0102.google.com") by vger.kernel.org with ESMTP id S965076AbWHQOpC (ORCPT ); Thu, 17 Aug 2006 10:45:02 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KcLDVVtbI+mIJ2QDHYxRhk/U9mpq8e/p4BYGXuxxnsBeSnmocWRfqzCrNXtQpao40uGUzzXkLVTHQkyrrNnijZY/XgchYdwIk13j0ZTjbA/QApdrDJd1AcM3GPZHGF/+0A+x8RlEpnP9Mmitu2BcwnaCxN37S1e3rAd2kKBtF8U= Message-ID: <6bffcb0e0608170745s8145df4ya4e946c76ab83c1b@mail.gmail.com> Date: Thu, 17 Aug 2006 16:45:02 +0200 From: "Michal Piotrowski" To: "Catalin Marinas" Subject: Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9 Cc: linux-kernel@vger.kernel.org, "Ingo Molnar" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060812215857.17709.79502.stgit@localhost.localdomain> <6bffcb0e0608130459k1c7e142esbfc2439badf323bd@mail.gmail.com> <6bffcb0e0608130726x8fc1c0v7717165a63391e80@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1614 Lines: 50 Hi Catalin, On 17/08/06, Catalin Marinas wrote: > On 13/08/06, Michal Piotrowski wrote: > > It's kmemleak 0.9 issue. I have tested kmemleak 0.8 on 2.6.18-rc1and > > 2.6.18-rc2. I haven't seen this before. > > it looks like it was caused by commit > fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls > slab_destroy() with l3->list_lock held. I'll revert this commit. > > The prio_tree use (which doesn't alloc memory) instead of the > radix_tree is about 4 times slower when scanning the memory and I > don't think I'll use it. > > It leaves me with the options of either implementing my own memory > allocator based on pages (including a simple hash table instead of > radix tree) or fix the locking in kmemleak so that memory allocations > happen without memleak_lock held. The latter is a bit complicated as > well since any slab allocation causes a re-entrance into kmemleak. > > Any other suggestions? Please talk with Christoph Lameter, he is working on Modular Slab. http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/0951.html http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0030.html Maybe he can help with this problem. > > Thanks. > > -- > Catalin > Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) - 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/