On 1/13/23 09:06, Dionna Amalie Glaze wrote:
> Thanks for your perspective, Dave. From what I understand,
> distributions lag behind, user kernel configurations can be varied,
> and Kirill's patch set is still untested with regards to memory
> latency of workloads. We may yet see folks opt for a slow boot for
> better latency. This protocol is for safety purposes, since "hope is
> not a strategy" as is commonly said at Google.
Hold on a sec though.
There are two basic strategies here:
1. Boot to userspace as fast as possible without accepting memory.
This runs apps more sooner after boot, but exposes those apps to the
latency of memory acceptance.
2. Accept all memory before running userspace. This makes the boot
slower but means that apps never see memory acceptance latency.
Kirill's _initial_ patch does #1. If anyone desperately wants #2, they
have mechanisms available to make a kernel with only #1 approximate #2.
A user on that kernel could allocate and memset()ing a bunch of memory.
Or, they could have a firmware stub accept the memory before booting the
real kernel.
It also doesn't rule out having a runtime knob or a boot parameter
implement #2. It's not a lot of code, but it involves new ABI.
However, *NONE* of this points me in the direction of saying that we
should have an OS/firmware protocol to negotiate whether the firmware or
OS does page acceptance other than the existing UEFI memory map bit.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98610): https://edk2.groups.io/g/devel/message/98610
Mute This Topic: https://groups.io/mt/96236145/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
