[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b169fde457f28e086c49c8a3b8d81ac539cfb59.camel@linux.intel.com>
Date: Fri, 07 Jan 2022 11:16:12 -0800
From: Kristen Carlson Accardi <kristen@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>, linux-sgx@...r.kernel.org,
Jarkko Sakkinen <jarkko@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] x86/sgx: Add accounting for tracking overcommit
On Fri, 2022-01-07 at 10:46 -0800, Dave Hansen wrote:
> On 1/7/22 10:16, Kristen Carlson Accardi wrote:
> > The overcommit percentage value is 150, which limits the total
> > number of
> > shared memory pages that may be consumed by all enclaves as backing
> > pages
> > to 1.5X of EPC pages on the system.
>
> Hi Kristen,
>
> Could you give some background on how this value was chosen and how
> it
> might impact userspace?
Yes,
The value of 1.5x the number of EPC pages was chosen because it will
handle the most common case of a few enclaves that don't need much
overcommit without any impact to user space. In the less commone case
where there are many enclaves or a few large enclaves which need a lot
of overcommit due to large EPC memory requirements, the reclaimer may
fail to allocate a backing page for swapping if the limit has been
reached. In this case the page will not be able to be reclaimed and the
system will not be able to allocate any new EPC pages. Any ioctl or
call to add new EPC pages will get -ENOMEM, so for example, new
enclaves will fail to load, and new EPC pages will not be able to be
added.
Does that make sense?
Kristen
Powered by blists - more mailing lists