Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3276636pxb; Fri, 5 Nov 2021 12:47:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQFAOGSSUW18QGoq0ns4WKMVueR8OsCU/xBe+csWTrFjTig9/2SOLGo6GiHJ6950Jhiq7p X-Received: by 2002:a50:9dca:: with SMTP id l10mr81355851edk.61.1636141673911; Fri, 05 Nov 2021 12:47:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636141673; cv=none; d=google.com; s=arc-20160816; b=v6bDgyqrlxYjTgfT/x/CvEvzedbnsguQGBL+8x4bQembzxjGXQqeJ7Eg6g5L6xdH8N a9AhOnbDYEkFUS9IoRTeb9cNnZxN0ldG5qg0UzgZc0/5vYzHS5FRhNkPDkn+EypsXvj+ FtZ7aRX+i0YASPJGmI/FPfgleAuSSW8oYMOIiF18HxCiIhXRDCbPXDiZtupjW3FpEqRF gh61Sb/+RARL9CQ9C2+BjK/eNH5HwbHLwXpyRmi0W5wb/4fV37ZGqx9Z8cChYqKnfuWV 6jxvVQ9VIAUuoT6mXOI22ncoGVKjFfr3JhoFcWAOqyOyxygUSriAt7ZC8o79G16+8qfY k6zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=nTlceYOcYTEl8/B0wV9RLjMXfgTBeKQZXRjMzBzUb8M=; b=MRwpZRR+KiBozJMsc9poQ16Z0gYWjdcmeiBKt8Maq54brl8Cyd3c27LppRb9RrdDzu K1kEWjY4aDa9J5NjJoa929DSc4ce+dUjvOdnu4J7/LZAIO4xAFnTC4Lp6zviWIgeCISn h+KCtl6dFB/kNIClx1T7Fn0vlKKRtmmEYkqIRYqEDtVBGb2TPiIf7taLp5Diu7KqnwVX bVh6u/T8PyTFS23bbDKoriHDldIm9jVxdSSiebgWoOYXoT2Ea3PbomJ3etzNoIor+9QY A9GAIDdc4o2U1mnozhjURWeVTzfFKqO1NwPMrzuFWpiEOq88OrKz8+O0MtnYQfu/Pofi HHgw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qk37si2739126ejc.360.2021.11.05.12.47.30; Fri, 05 Nov 2021 12:47:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231842AbhKESli (ORCPT + 99 others); Fri, 5 Nov 2021 14:41:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:49410 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232730AbhKESli (ORCPT ); Fri, 5 Nov 2021 14:41:38 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EAB9F61131; Fri, 5 Nov 2021 18:38:55 +0000 (UTC) Date: Fri, 5 Nov 2021 18:38:52 +0000 From: Catalin Marinas To: Qian Cai Cc: Will Deacon , Mike Rapoport , Andrew Morton , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Russell King , kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] arm64: Track no early_pgtable_alloc() for kmemleak Message-ID: References: <20211105150509.7826-1-quic_qiancai@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211105150509.7826-1-quic_qiancai@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 05, 2021 at 11:05:09AM -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 Reviewed-by: Catalin Marinas