Received-SPF: pass (google.com: domain of linux-kernel+bounces-136652-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
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
From: Itaru Kitayama <itaru.kitayama@linux.dev>
In-Reply-To: <1d5abb48-08a8-4d83-a681-6915bc7b6907@arm.com>
Date: Tue, 9 Apr 2024 19:13:38 +0900
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
 Will Deacon <will@kernel.org>,
 Mark Rutland <Mark.Rutland@arm.com>,
 Ard Biesheuvel <ardb@kernel.org>,
 David Hildenbrand <david@redhat.com>,
 Donald Dutile <ddutile@redhat.com>,
 Eric Chanudet <echanude@redhat.com>,
 Linux ARM <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <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>
 <Zg+qwooaWFNL7KIg@vm3> <fd4aed3a-42be-44e0-b3bb-12f77c5911a1@arm.com>
 <ZhEkif45F0aVvKPx@vm3> <533adb77-8c2b-40db-84cb-88de77ab92bb@arm.com>
 <FCDCBCEE-7D97-4769-AB95-7294A9CE18E0@linux.dev>
 <1d5abb48-08a8-4d83-a681-6915bc7b6907@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>


> On Apr 9, 2024, at 19:04, Ryan Roberts <ryan.roberts@arm.com> wrote:
>=20
> On 09/04/2024 01:10, Itaru Kitayama wrote:
>> Hi Ryan,
>>=20
>>> On Apr 8, 2024, at 16:30, Ryan Roberts <ryan.roberts@arm.com> 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/<https://lore.kernel.org/linux-arm-kernel/20240326101448.3453=
626-1-ryan.roberts@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.