lkml.org 
[lkml]   [2022]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCHv7 02/14] mm: Add support for unaccepted memory
>
>
> 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

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



--
-Dionna Glaze, PhD (she/her)

\
 
 \ /
  Last update: 2022-09-17 16:27    [W:2.014 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site