From: "Haitao Huang" <haitao.huang@linux.intel.com>
To: linux-sgx@vger.kernel.org, "Jarkko Sakkinen" <jarkko@kernel.org>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Kristen Carlson Accardi" <kristen@linux.intel.com>,
"Dave Hansen" <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] x86/sgx: Add accounting for tracking overcommit
Date: Tue, 11 Jan 2022 10:33:26 -0600 [thread overview]
Message-ID: <op.1fuaql06wjvjmi@hhuan26-mobl1.mshome.net> (raw)
In-Reply-To: <bc370c39-d8c1-9371-2345-cf255ced9a1b@intel.com>
On Tue, 11 Jan 2022 09:43:35 -0600, Dave Hansen <dave.hansen@intel.com>
wrote:
> On 1/11/22 06:20, Haitao Huang wrote:
>> If the system has a ton of RAM but limited EPC, I think it makes sense
>> to allow more EPC swapping, can we do min(0.5*RAM, 2*EPC)?
>> I suppose if the system is used for heavy enclave load, user would be
>> willing to at least use half of RAM.
>
> If I have 100GB of RAM and 100MB of EPC, can I really *meaningfully* run
> 50GB of enclaves? In that case, if everything was swapped out evenly, I
> would only have a 499/500 chance that a given page reference would fault.
>
The formula will cap swapping at 2*EPC so only 200MB swapped out. So the
miss is at most 1/3.
The original hard coded cap 1.5*EPC may still consume too much RAM if
RAM<1.5*EPC.
> This isn't about a "heavy enclave load". If there is *that* much
> swapped-out enclave memory, will an enclave even make meaningful forward
> progress?
next prev parent reply other threads:[~2022-01-11 16:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 18:16 [PATCH v2 0/2] x86/sgx: Limit EPC overcommit Kristen Carlson Accardi
2022-01-07 18:16 ` [PATCH v2 1/2] x86/sgx: Add accounting for tracking overcommit Kristen Carlson Accardi
2022-01-07 18:46 ` Dave Hansen
2022-01-07 19:16 ` Kristen Carlson Accardi
2022-01-11 14:20 ` Haitao Huang
2022-01-11 15:43 ` Dave Hansen
2022-01-11 16:33 ` Haitao Huang [this message]
2022-01-11 17:39 ` Dave Hansen
2022-01-14 17:45 ` Kristen Carlson Accardi
2022-01-08 15:59 ` Jarkko Sakkinen
2022-01-14 17:47 ` Kristen Carlson Accardi
2022-01-07 18:16 ` [PATCH v2 2/2] x86/sgx: account backing pages Kristen Carlson Accardi
2022-01-08 16:05 ` Jarkko Sakkinen
2022-01-14 17:51 ` Kristen Carlson Accardi
2022-01-14 17:55 ` Dave Hansen
2022-01-14 23:57 ` Jarkko Sakkinen
2022-01-15 0:16 ` Dave Hansen
2022-01-15 0:56 ` Jarkko Sakkinen
2022-01-14 23:52 ` Jarkko Sakkinen
2022-01-14 23:55 ` Dave Hansen
2022-01-15 0:58 ` Jarkko Sakkinen
2022-01-15 18:57 ` [PATCH v2 0/2] x86/sgx: Limit EPC overcommit Jarkko Sakkinen
2022-01-15 19:02 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.1fuaql06wjvjmi@hhuan26-mobl1.mshome.net \
--to=haitao.huang@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=kristen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.