From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by mx.groups.io with SMTP id smtpd.web11.95297.1673632628711174586
 for <devel@edk2.groups.io>;
 Fri, 13 Jan 2023 09:57:08 -0800
Authentication-Results: mx.groups.io;
 dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=j3lXjzyT;
 spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: dave.hansen@intel.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1673632628; x=1705168628;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=G5YGrCXRTCi3wjZQ89AhJuHawjeSvtoQ+Kgf0+sQOWs=;
  b=j3lXjzyTAS609j1EinQx/6nNtn5P+REex2PiWUQzFZcQuY6ulbnWulRY
   68PHhe7uN1hOYestPMJ32ZYCgKpnbkRs+E/atkDCOz4pWeq4C7jjRwFrN
   ASpLRSEzF65Aj38xLkV+1sIuuFexAkZcmdHmHtbnf66ohRp60B0vK4yzf
   mNFsGfEJE3NW/+GpUuke8Vy5Q1PM++ygHxbmok/iPrezlDpQVfl8jpRK5
   Wa6Xv8YwMfoOhEMUf5oMpT2vUTX2v3k5afAPDd/+pZTHVoAEk4OIe2+z8
   jgRtbsCccGJJBesRxkKslj1g+NZnShpZXPc5l3DoijzIkmq/sUsBPrOhJ
   w==;
X-IronPort-AV: E=McAfee;i="6500,9779,10589"; a="311907720"
X-IronPort-AV: E=Sophos;i="5.97,214,1669104000"; 
   d="scan'208";a="311907720"
Received: from orsmga005.jf.intel.com ([10.7.209.41])
  by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2023 09:57:08 -0800
X-IronPort-AV: E=McAfee;i="6500,9779,10589"; a="832141668"
X-IronPort-AV: E=Sophos;i="5.97,214,1669104000"; 
   d="scan'208";a="832141668"
Received: from cnjohnso-mobl1.amr.corp.intel.com (HELO [10.209.49.126]) ([10.209.49.126])
  by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2023 09:57:07 -0800
Message-ID: <0918b9db-c949-75ce-a24e-f12f03865938@intel.com>
Date: Fri, 13 Jan 2023 09:57:07 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior
To: Dionna Amalie Glaze <dionnaglaze@google.com>, devel@edk2.groups.io,
 dave.hansen@linux.intel.com
Cc: Jiewen <jiewen.yao@intel.com>,
 "Shutemov, Kirill" <kirill.shutemov@intel.com>
References: <MW4PR11MB58725ED9D912BDC299E821538CC29@MW4PR11MB5872.namprd11.prod.outlook.com>
 <16581.1673625639418051810@groups.io>
 <CAAH4kHYgN1ZVevP7mDRT27bpjj+0tkyAVbtznzyfYVuryBU=2g@mail.gmail.com>
From: Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <CAAH4kHYgN1ZVevP7mDRT27bpjj+0tkyAVbtznzyfYVuryBU=2g@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.