[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2981e25e-9cda-518a-9750-b8694f2356b5@amd.com>
Date: Mon, 15 Aug 2022 17:02:25 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>,
Mel Gorman <mgorman@...hsingularity.net>
Cc: Vlastimil Babka <vbabka@...e.cz>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Sean Christopherson <seanjc@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Joerg Roedel <jroedel@...e.de>,
Ard Biesheuvel <ardb@...nel.org>,
Andi Kleen <ak@...ux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Dario Faggioli <dfaggioli@...e.com>,
Dave Hansen <dave.hansen@...el.com>,
Mike Rapoport <rppt@...nel.org>,
David Hildenbrand <david@...hat.com>,
Marcelo Cerri <marcelo.cerri@...onical.com>,
tim.gardner@...onical.com,
Khalid ElMously <khalid.elmously@...onical.com>,
philip.cox@...onical.com,
the arch/x86 maintainers <x86@...nel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
linux-coco@...ts.linux.dev, linux-efi <linux-efi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mike Rapoport <rppt@...ux.ibm.com>
Subject: Re: [PATCHv7 02/14] mm: Add support for unaccepted memory
On 8/15/22 16:08, Dionna Amalie Glaze wrote:
>>
>>
>> The unpredictable performance of the application early in boot may be
>> unacceptable and unavoidable. It might take a long time but it could
>> eventually generate bug reports about "unpredictable performance early
>> in boot" that will be hard to track down unless accept_memory is observed
>> using perf at the right time. Even when that does happen, there will need
>> to be an option to turn it off if the unpredictable performance cannot
>> be tolerated. Second, any benchmarking done early in boot is likely to
>> be disrupted making the series a potential bisection magnet that masks a
>> performance bug elsewhere in the merge window.
>
> I'm doing some boot performance tests now before I run some workload
> memory acceptance latency tests.
> Note that this testing is on AMD SEV-SNP, so this patch series on top
> of the AMD guest patches v12, plus a
> patch Brijesh Singh wrote to define __accept_memory for SEV-SNP
> https://github.com/AMDESE/linux/commit/ecae2582666d50ce1e633975d703d2f904183ece
Note that there is a bug in Brijesh's version of the patch and it will
almost exclusively use the MSR protocol. Please try the version of the
patch that I recently sent up based on the current unaccepted memory tree
from Kirill.
https://lore.kernel.org/lkml/cover.1660579062.git.thomas.lendacky@amd.com/
Thanks,
Tom
>
> I was getting pretty consistent boot times, only going up slightly as
> the memory size increased, but at 256GB, the VM crashes because it
> touches some unaccepted memory without first accepting it. 255GB boots
> fine.
>
> The stack track is in mm/page_alloc.c. I've done a little
> investigation, but I can't account for why there's a hard cutoff of
> correctness at 256GB
>
> [ 0.065563] RIP: 0010:memmap_init_range+0x108/0x173
> [ 0.066309] Code: 77 16 f6 42 10 02 74 10 48 03 42 08 48 c1 e8 0c
> 48 89 c3 e9 3a ff ff ff 48 89 df 48 c1 e7 06 48 03 3d d9 a2 66 ff 48
> 8d 47 08 <c7> 47 34 01 00 00 00 48 c7 47 38 00 00 00 00 c7 47 30 ff ff
> ff ff
> [ 0.069108] RSP: 0000:ffffffffad603dc8 EFLAGS: 00010082 ORIG_RAX:
> 0000000000000404
> [ 0.070193] RAX: ffffdba740000048 RBX: 0000000000000001 RCX: 0000000000000000
> [ 0.071170] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffdba740000040
> [ 0.072224] RBP: 0000000000000000 R08: 0000000000001000 R09: 0000000000000000
> [ 0.073283] R10: 0000000000000001 R11: ffffffffad645c60 R12: 0000000000000000
> [ 0.074304] R13: 00000000000000a0 R14: 0000000000000000 R15: 0000000000000000
> [ 0.075285] FS: 0000000000000000(0000) GS:ffffffffadd6c000(0000)
> knlGS:0000000000000000
> [ 0.076365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.077194] CR2: ffffdba740000074 CR3: 0008001ee3a0c000 CR4: 00000000000606b0
> [ 0.078209] Call Trace:
> [ 0.078524] <TASK>
> [ 0.078887] ? free_area_init+0x5c1/0x66c
> [ 0.079417] ? zone_sizes_init+0x52/0x6c
> [ 0.079934] ? setup_arch+0xa55/0xb6d
> [ 0.080417] ? start_kernel+0x64/0x65a
> [ 0.080897] ? secondary_startup_64_no_verify+0xd6/0xdb
> [ 0.081620] </TASK>
>
>>
>> --
>> Mel Gorman
>> SUSE Labs
>
>
>
Powered by blists - more mailing lists