From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B30267E101 for ; Tue, 9 Apr 2024 10:14:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712657644; cv=none; b=o3QEXFcZSeNr6KUHTmq/BBD+nBZ9c4ObcXQSSjGxa57+o8uCei9hVpRJ5/2rC47nVgIFWzsAAtX6UBMkMfSIl5GYWPFP9qNgw4mv4eFocOB/ESQo8MDwnu+pIqDJ1MjAwzhwTP6KOkqNLnPqoY4bmRHyCCncEelEs3+JwsrEWug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712657644; c=relaxed/simple; bh=f9vTCZeazc+cC9E9m3sp3ek3199iY8AYYqVbk3yPnmo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Rcq+hU6yNys1yZuwRCaQ5oon2/lBRrPr9Pe/rwMi4q8yUHPOOxhU9545y9vNbjkc/XoceSL9EOwtBkXiyK0tqfPv6LHLqwe+KC2rvwuAZh8FJnytKQUthAZEpnOKjBhiS2Jb1zmD6cFw27EN2aZn7DgX5XB6WtZyqOAFPx+QwPI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=iUDqfsYX; arc=none smtp.client-ip=91.218.175.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="iUDqfsYX" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712657638; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I6NjstxZg5zzcu4zkmXOrIo4bbiuOWeKiARFgfpV5y0=; b=iUDqfsYXaSTkwJFoNMKuNMtWigcM0vWSQp9JgveKOMBBIMhWIPR72fJBxTztFtL5y0e/3u E0bUZkisG3H9EcD2wQvxCfjWKE245hTc5sqVs2gGxde8j1QhLPyTau/KGcg1+zGv0QMAAP YXa5yFwRH55ZHHq71hR99gsxEQcM+6M= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: [PATCH v2 0/4] Speed up boot with faster linear map creation X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Itaru Kitayama In-Reply-To: <1d5abb48-08a8-4d83-a681-6915bc7b6907@arm.com> Date: Tue, 9 Apr 2024 19:13:38 +0900 Cc: Catalin Marinas , Will Deacon , Mark Rutland , Ard Biesheuvel , David Hildenbrand , Donald Dutile , Eric Chanudet , Linux ARM , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: quoted-printable Message-Id: <268FBD1C-B102-4726-A7F4-1125123BDA7A@linux.dev> References: <20240404143308.2224141-1-ryan.roberts@arm.com> <533adb77-8c2b-40db-84cb-88de77ab92bb@arm.com> <1d5abb48-08a8-4d83-a681-6915bc7b6907@arm.com> To: Ryan Roberts X-Migadu-Flow: FLOW_OUT > On Apr 9, 2024, at 19:04, Ryan Roberts wrote: >=20 > On 09/04/2024 01:10, Itaru Kitayama wrote: >> Hi Ryan, >>=20 >>> On Apr 8, 2024, at 16:30, Ryan Roberts wrote: >>>=20 >>> On 06/04/2024 11:31, Itaru Kitayama wrote: >>>> Hi Ryan, >>>>=20 >>>> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote: >>>>> Hi Itaru, >>>>>=20 >>>>> On 05/04/2024 08:39, Itaru Kitayama wrote: >>>>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, Ryan Roberts wrote: >>>>>>> Hi All, >>>>>>>=20 >>>>>>> It turns out that creating the linear map can take a significant = proportion of >>>>>>> the total boot time, especially when rodata=3Dfull. 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. >>>>>>>=20 >>>>>>> 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): >>>>>>>=20 >>>>>>> | 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%) >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> --- >>>>>>>=20 >>>>>>> Changes since v1 [1] >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> - 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. >>>>>>>=20 >>>>>>>=20 >>>>>>> [1] = https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.rob= erts@arm.com/ >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Ryan >>>>>>>=20 >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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(-) >>>>>>>=20 >>>>>>> -- >>>>>>> 2.25.1 >>>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> Thanks for taking a look at this. >>>>>=20 >>>>> I can't reproduce your issue unfortunately; steps as follows on = Apple M2 VM: >>>>>=20 >>>>> Config: arm64 defconfig + the following: >>>>>=20 >>>>> # 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 >>>>>=20 >>>>> # 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 >>>>>=20 >>>>> # For mm selftests. >>>>> ./scripts/config --enable CONFIG_USERFAULTFD >>>>> ./scripts/config --enable CONFIG_TEST_VMALLOC >>>>> ./scripts/config --enable CONFIG_GUP_TEST >>>>>=20 >>>>> 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: >>>>>=20 >>>>> " >>>>> transparent_hugepage=3Dmadvise earlycon root=3D/dev/vda2 = secretmem.enable >>>>> hugepagesz=3D1G hugepages=3D0:2,1:2 hugepagesz=3D32M = hugepages=3D0:2,1:2 >>>>> default_hugepagesz=3D2M hugepages=3D0:64,1:64 hugepagesz=3D64K = hugepages=3D0:2,1:2 >>>>> " >>>>>=20 >>>>> Ubuntu userspace running off XFS rootfs. Build and run mm = selftests from same >>>>> git tree. >>>>>=20 >>>>>=20 >>>>> Although I don't think any of this config should make a difference = to gup_longterm. >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> Attached is the strace=E2=80=99d gup_longterm executiong log on your >> pgtable-boot-speedup-v2 kernel. >=20 > Sorry are you saying that it only fails with the = pgtable-boot-speedup-v2 patch > set applied? I thought we previously concluded that it was independent = of that? > I was under the impression that it was filesystem related and not = something that > I was planning to investigate. No, irrespective of the kernel, if using 9p on FVP the test program = fails. It is indeed 9p filesystem related, as I switched to using NFS all the = issues are gone. Thanks, Itaru. >=20 >>=20 >> Thanks, >> Itaru. >>=20 >>> Thanks, >>> Ryan >>>=20 >>>>=20 >>>> Thanks, >>>> Itaru. >>>>=20 >>>>>=20 >>>>> Does this problem reproduce with v6.9-rc2, without my patches? I = except it >>>>> probably does? >>>>>=20 >>>>> Thanks, >>>>> Ryan >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Itaru.