Received: by 2002:ab2:3350:0:b0:1f4:6588:b3a7 with SMTP id o16csp1178546lqe; Mon, 8 Apr 2024 00:30:52 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUyHyH/M532WDt3RCJP+M3WHphrId9trWXiP2n0JMA6OguGEffwunqJ7RQXCuV/CKuXTBhFe1ktt6FEZUnPMvoydAebcLfTM34kyrGRgg== X-Google-Smtp-Source: AGHT+IH89GGQMSfuis5Hd895IcUzie9BVFoxLtaRQiP9sIH8ysY2sPYS+CMF+9gGAjJG/9UsDXDe X-Received: by 2002:a05:622a:2d3:b0:434:8f15:b32 with SMTP id a19-20020a05622a02d300b004348f150b32mr3053796qtx.7.1712561452051; Mon, 08 Apr 2024 00:30:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712561452; cv=pass; d=google.com; s=arc-20160816; b=nCp86Te94rvldsBvM4tqTj0cQrAObfNExtpc9uMH5qZqcruAnqkv/3RU3OY+mB7/4n X1T91K3egq2zRD3KIliCOL7CIAbeJ84gAZYWw6+8AJ0xVRUZGmexqsEH2cQ0SM6vsvdr GH9+GbeKgrnQ1gULiKRCnLbrKi7XCRgmfsm8VFVw48biwVP97UD7CtlSotMqk/FhVik+ /ka7jRn7hrhhFeg89PJ26sAhS1zBEPM+mQrz7cSZNcRW9Fg+X8eIzjb6bbIzlRtyIp5s sshFkDS72p9cmUF6ZX4i1hIWpoLSMODvEH9fPxacM2OiRJpKFSNjs+q9jkOSv0pwXUar AXEw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=V6tod5NwdsuytNSZsavmXbXDfqmYeQCCGTazRE3QNXc=; fh=BNVJY/C+bzBRzpbH29IYXpHWNfP2KKOTdpE/vG80BBs=; b=syLQgbLg6bOM/AqhFaSEsiXJFOOs4gEhCCo3CgE5b6dOUkulSlWZ28MLdD4aebrqtc IUGdh4YpIuClLx8b/CBNItkib+L3T6prs32atOBf3R7S3NMf3g+ww5aB72UWpY1CN1Ne TxS+Hnh99bZAEUgAIM1b8v5IAySlXdsI8Ym6WtTDttZ0O2w/vU+pq2rFt3xlEX8o+jDY a8SDR+Z1W6u0rSsSl9wo2ftsAHvRz4DtQ8Qapq27xjlsZmVGXLF8PJ8mRyABUSECMFUC yY8riWAgxdxugxfYlTpL+KOuS2Igscv3MYdDqw0xKLBDhZko//RfyTQ8ulhLCEWhrohN REMw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-134901-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134901-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id 18-20020ac85952000000b0043467e02551si6135096qtz.486.2024.04.08.00.30.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Apr 2024 00:30:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-134901-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-134901-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-134901-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 678DD1C21B1E for ; Mon, 8 Apr 2024 07:30:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A1E925619; Mon, 8 Apr 2024 07:30:45 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8110224B2F for ; Mon, 8 Apr 2024 07:30:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712561444; cv=none; b=Ob/es0z7z6Me+MzcJ6gnnT9zKtFINKvOeVY8oR9wOVZ+KAc4b40wFiLfhYt9J/7YoUcpm0nKRHvwS8JGDAoS7jGzMS9HKYP3BRZjKMy+iR2+mhsC62A7VXY+/ZoEQHAmIlNq52oiCvVXQUEgsLXoEoNXbD4+WnO/zzvQsf3uSMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712561444; c=relaxed/simple; bh=XYJsF0RgC5u+B3iimuS2ScRDOTFUcvmpGeRi1MIQLDM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gus3P/Xp4UobrN8P/1yxDZIlGOp4TEcsjIiC9cgC/fPrWwz/zIJzDwc23W01x34jdMvNrupzd7BZ7MHqDzUaKtPw4g6sqIleyz3aK6aZRVtaV4XzK8c9a/9lsKcoLOB3+FzLrvckZD8kCSTlppwkQhUJyNlh+sPGMq9RudR7wSQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1820B1007; Mon, 8 Apr 2024 00:31:12 -0700 (PDT) Received: from [10.57.73.169] (unknown [10.57.73.169]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4635B3F64C; Mon, 8 Apr 2024 00:30:40 -0700 (PDT) Message-ID: <533adb77-8c2b-40db-84cb-88de77ab92bb@arm.com> Date: Mon, 8 Apr 2024 08:30:38 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/4] Speed up boot with faster linear map creation Content-Language: en-GB To: Itaru Kitayama Cc: Catalin Marinas , Will Deacon , Mark Rutland , Ard Biesheuvel , David Hildenbrand , Donald Dutile , Eric Chanudet , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20240404143308.2224141-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06/04/2024 11:31, Itaru Kitayama wrote: > Hi Ryan, > > On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote: >> Hi Itaru, >> >> On 05/04/2024 08:39, Itaru Kitayama wrote: >>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote: >>>> Hi All, >>>> >>>> It turns out that creating the linear map can take a significant proportion of >>>> the total boot time, especially when rodata=full. And most of the time is spent >>>> waiting on superfluous tlb invalidation and memory barriers. This series reworks >>>> the kernel pgtable generation code to significantly reduce the number of those >>>> TLBIs, ISBs and DSBs. See each patch for details. >>>> >>>> The below shows the execution time of map_mem() across a couple of different >>>> systems with different RAM configurations. We measure after applying each patch >>>> and show the improvement relative to base (v6.9-rc2): >>>> >>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra >>>> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G >>>> ---------------|-------------|-------------|-------------|------------- >>>> | ms (%) | ms (%) | ms (%) | ms (%) >>>> ---------------|-------------|-------------|-------------|------------- >>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%) >>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%) >>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656 (-91%) >>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257 (-93%) >>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838 (-95%) >>>> >>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've compile and >>>> boot tested various PAGE_SIZE and VA size configs. >>>> >>>> --- >>>> >>>> Changes since v1 [1] >>>> ==================== >>>> >>>> - Added Tested-by tags (thanks to Eric and Itaru) >>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard) >>>> - Reordered patches (biggest impact & least controversial first) >>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader >>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync() >>>> - Reverted generic p4d_index() which caused x86 build error. Replaced with >>>> unconditional p4d_index() define under arm64. >>>> >>>> >>>> [1] https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/ >>>> >>>> Thanks, >>>> Ryan >>>> >>>> >>>> Ryan Roberts (4): >>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block >>>> arm64: mm: Batch dsb and isb when populating pgtables >>>> arm64: mm: Don't remap pgtables for allocate vs populate >>>> arm64: mm: Lazily clear pte table mappings from fixmap >>>> >>>> arch/arm64/include/asm/fixmap.h | 5 +- >>>> arch/arm64/include/asm/mmu.h | 8 + >>>> arch/arm64/include/asm/pgtable.h | 13 +- >>>> arch/arm64/kernel/cpufeature.c | 10 +- >>>> arch/arm64/mm/fixmap.c | 11 + >>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++-------- >>>> 6 files changed, 319 insertions(+), 105 deletions(-) >>>> >>>> -- >>>> 2.25.1 >>>> >>> >>> I've build and boot tested the v2 on FVP, base is taken from your >>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not oks, would you take a look at it? The mm ksefltests used is from your linux-rr repo too. >> >> Thanks for taking a look at this. >> >> I can't reproduce your issue unfortunately; steps as follows on Apple M2 VM: >> >> Config: arm64 defconfig + the following: >> >> # Squashfs for snaps, xfs for large file folios. >> ./scripts/config --enable CONFIG_SQUASHFS_LZ4 >> ./scripts/config --enable CONFIG_SQUASHFS_LZO >> ./scripts/config --enable CONFIG_SQUASHFS_XZ >> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD >> ./scripts/config --enable CONFIG_XFS_FS >> >> # For general mm debug. >> ./scripts/config --enable CONFIG_DEBUG_VM >> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE >> ./scripts/config --enable CONFIG_DEBUG_VM_RB >> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS >> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE >> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK >> >> # For mm selftests. >> ./scripts/config --enable CONFIG_USERFAULTFD >> ./scripts/config --enable CONFIG_TEST_VMALLOC >> ./scripts/config --enable CONFIG_GUP_TEST >> >> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes (needed by >> some mm selftests), with kernel command line to reserve hugetlbs and other >> features required by some mm selftests: >> >> " >> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable >> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2 >> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K hugepages=0:2,1:2 >> " >> >> Ubuntu userspace running off XFS rootfs. Build and run mm selftests from same >> git tree. >> >> >> Although I don't think any of this config should make a difference to gup_longterm. >> >> Looks like your errors are all "ftruncate() failed". I've seen this problem on >> our CI system. There it is due to running the tests from NFS file system. What >> filesystem are you using? Perhaps you are sharing into the FVP using 9p? That >> might also be problematic. > > That was it. This time I booted up the kernel including your series on > QEMU on my M1 and executed the gup_longterm program without the ftruncate > failures. When testing your kernel on FVP, I was executing the script from the FVP's host filesystem using 9p. I'm not sure exactly what the root cause is. Perhaps there isn't enough space on the disk? It might be worth enhancing the error log to provide the errno in tools/testing/selftests/mm/gup_longterm.c. Thanks, Ryan > > Thanks, > Itaru. > >> >> Does this problem reproduce with v6.9-rc2, without my patches? I except it >> probably does? >> >> Thanks, >> Ryan >> >>> >>> Thanks, >>> Itaru. >>