From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D98EC433EF for ; Thu, 4 Nov 2021 17:08:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0110A610D0 for ; Thu, 4 Nov 2021 17:08:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0110A610D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=j4DA7JhRMohTEkLDyWj7pEOmiKix3iJSlGijB6BT+D4=; b=cTR4Je6JgPfaim k7D9VJS7VV0934ZGHxe1i9oPf51kAmO/ziJCsd0b1rfhQ1l/+1N8MxG8QH8iyEMhBZZ+tF/v0DfFM wtn+M7NkRqUSs3GNeQ2/psuZr6o+keb8WgQbGsEPLYx/7fJ+aX7hvE5DNEMXkNcmPqmshtj1Ej7Uu dLGTwK31lK3u6FjP528YwaNKst8foHO30J90hkmlLLXE1TaAY7fsX5occghxrPoBibCP4yOUB45qH 0+dVDv9OImjt96flJSj+K3RWnXGmx3d+flAJmnK/9FW5fohgO4UoF+WVA+MMpWc79HLvc9VtizQAl A7+r696AE6wI8a7fVmiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1migCc-009aWG-In; Thu, 04 Nov 2021 17:07:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1migCY-009aUr-GA for linux-arm-kernel@lists.infradead.org; Thu, 04 Nov 2021 17:07:00 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id ABFA1610D0; Thu, 4 Nov 2021 17:06:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636045617; bh=Q3KX2xW1zpDKC4VCay8v5kQG0LBSrEoOWXthl7qQ75M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P4QNo0A9mr/WTpiiuz3anR4j9IobduIOiuN/xQGGwGodsGglMp7u+GI4+jgH4a6Zp RL3U8tfV10mmBYP03eKtftn6mE8TVeA+YO6q/DEb6BWlU2UuUql2D91YMKgYJyUy7J YQsat4iwNWPuw8lpXwNBnpjj24ept6JctMfquT/l8eqyUFFzdSnqYISedKHgiZxVyv GM+X2iALzm/6koRNVvQoaptIHOQkTlsB3E892euIfqhMwpVy49WC3etlfTro4w98jk QwfEZ95nwWq2GGsGWSMHA4L2t3Uw+ImrMQAr6p9TYdi8UHiXQtyeISFgSlJUhXjbeZ 6mxCvtp5Q5h7Q== Date: Thu, 4 Nov 2021 19:06:49 +0200 From: Mike Rapoport To: Qian Cai Cc: Catalin Marinas , Will Deacon , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: Track no early_pgtable_alloc() for kmemleak Message-ID: References: <20211104155623.11158-1-quic_qiancai@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211104155623.11158-1-quic_qiancai@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_100658_630541_208B7420 X-CRM114-Status: GOOD ( 27.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 04, 2021 at 11:56:23AM -0400, Qian Cai wrote: > After switched page size from 64KB to 4KB on several arm64 servers here, > kmemleak starts to run out of early memory pool due to a huge number of > those early_pgtable_alloc() calls: > > kmemleak_alloc_phys() > memblock_alloc_range_nid() > memblock_phys_alloc_range() > early_pgtable_alloc() > init_pmd() > alloc_init_pud() > __create_pgd_mapping() > __map_memblock() > paging_init() > setup_arch() > start_kernel() > > Increased the default value of DEBUG_KMEMLEAK_MEM_POOL_SIZE by 4 times > won't be enough for a server with 200GB+ memory. There isn't much > interesting to check memory leaks for those early page tables and those > early memory mappings should not reference to other memory. Hence, no > kmemleak false positives, and we can safely skip tracking those early > allocations from kmemleak like we did in the commit fed84c785270 > ("mm/memblock.c: skip kmemleak for kasan_init()") without needing to > introduce complications to automatically scale the value depends on the > runtime memory size etc. After the patch, the default value of > DEBUG_KMEMLEAK_MEM_POOL_SIZE becomes sufficient again. > > Signed-off-by: Qian Cai > --- > arch/arm64/mm/mmu.c | 3 ++- > include/linux/memblock.h | 1 + > mm/memblock.c | 10 +++++++--- > 3 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index d77bf06d6a6d..4d3cfbaa92a7 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -96,7 +96,8 @@ static phys_addr_t __init early_pgtable_alloc(int shift) > phys_addr_t phys; > void *ptr; > > - phys = memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE); > + phys = memblock_phys_alloc_range(PAGE_SIZE, PAGE_SIZE, 0, > + MEMBLOCK_ALLOC_PGTABLE); > if (!phys) > panic("Failed to allocate page table page\n"); > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > index 7df557b16c1e..de903055b01c 100644 > --- a/include/linux/memblock.h > +++ b/include/linux/memblock.h > @@ -390,6 +390,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) > #define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0) > #define MEMBLOCK_ALLOC_ACCESSIBLE 0 > #define MEMBLOCK_ALLOC_KASAN 1 > +#define MEMBLOCK_ALLOC_PGTABLE 2 > > /* We are using top down, so it is safe to use 0 here */ > #define MEMBLOCK_LOW_LIMIT 0 > diff --git a/mm/memblock.c b/mm/memblock.c > index 659bf0ffb086..13bc56a641c0 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -287,7 +287,8 @@ static phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, > { > /* pump up @end */ > if (end == MEMBLOCK_ALLOC_ACCESSIBLE || > - end == MEMBLOCK_ALLOC_KASAN) > + end == MEMBLOCK_ALLOC_KASAN || > + end == MEMBLOCK_ALLOC_PGTABLE) I think I'll be better to rename MEMBLOCK_ALLOC_KASAN to, say, MEMBLOCK_ALLOC_NOKMEMLEAK and use that for both KASAN and page table cases. But more generally, we are going to hit this again and again. Couldn't we add a memblock allocation as a mean to get more memory to kmemleak::mem_pool_alloc()? > end = memblock.current_limit; > > /* avoid allocating the first page */ > @@ -1387,8 +1388,11 @@ phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > return 0; > > done: > - /* Skip kmemleak for kasan_init() due to high volume. */ > - if (end != MEMBLOCK_ALLOC_KASAN) > + /* > + * Skip kmemleak for kasan_init() and early_pgtable_alloc() due to high > + * volume. > + */ > + if (end != MEMBLOCK_ALLOC_KASAN && end != MEMBLOCK_ALLOC_PGTABLE) > /* > * The min_count is set to 0 so that memblock allocated > * blocks are never reported as leaks. This is because many > -- > 2.30.2 > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel