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 98228C433EF for ; Thu, 4 Nov 2021 17:07:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E21F61186 for ; Thu, 4 Nov 2021 17:07:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3E21F61186 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7B3996B006C; Thu, 4 Nov 2021 13:06:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73CAE6B0072; Thu, 4 Nov 2021 13:06:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 603036B0073; Thu, 4 Nov 2021 13:06:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 4DB346B006C for ; Thu, 4 Nov 2021 13:06:59 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 041FD8249980 for ; Thu, 4 Nov 2021 17:06:59 +0000 (UTC) X-FDA: 78771877758.08.A4F7E8E Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP id 2BB20D0000A3 for ; Thu, 4 Nov 2021 17:06:48 +0000 (UTC) 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211104155623.11158-1-quic_qiancai@quicinc.com> Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=P4QNo0A9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2BB20D0000A3 X-Stat-Signature: cgcpbw8m14xjeq8t4m58few4q5e9x5q7 X-HE-Tag: 1636045608-457446 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.