From: "Huang, Kai" <kai.huang@intel.com>
To: "hpa@zytor.com" <hpa@zytor.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jarkko@kernel.org" <jarkko@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"haitao.huang@linux.intel.com" <haitao.huang@linux.intel.com>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"tj@kernel.org" <tj@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>
Cc: "kristen@linux.intel.com" <kristen@linux.intel.com>,
"yangjie@microsoft.com" <yangjie@microsoft.com>,
"Li, Zhiquan1" <zhiquan1.li@intel.com>, "Christopherson,,
Sean" <seanjc@google.com>,
"mikko.ylinen@linux.intel.com" <mikko.ylinen@linux.intel.com>,
"Zhang, Bo" <zhanb@microsoft.com>,
"anakrish@microsoft.com" <anakrish@microsoft.com>
Subject: Re: [PATCH v5 16/18] x86/sgx: Limit process EPC usage with misc cgroup controller
Date: Tue, 10 Oct 2023 00:26:01 +0000 [thread overview]
Message-ID: <0005a998dab64c182c22abc436cbcd36de4240a1.camel@intel.com> (raw)
In-Reply-To: <20230923030657.16148-17-haitao.huang@linux.intel.com>
> @@ -332,6 +336,7 @@ void sgx_isolate_epc_pages(struct sgx_epc_lru_lists *lru, size_t nr_to_scan,
> * sgx_reclaim_epc_pages() - Reclaim EPC pages from the consumers
> * @nr_to_scan: Number of EPC pages to scan for reclaim
> * @ignore_age: Reclaim a page even if it is young
> + * @epc_cg: EPC cgroup from which to reclaim
> *
> * Take a fixed number of pages from the head of the active page pool and
> * reclaim them to the enclave's private shmem files. Skip the pages, which have
> @@ -345,7 +350,8 @@ void sgx_isolate_epc_pages(struct sgx_epc_lru_lists *lru, size_t nr_to_scan,
> * problematic as it would increase the lock contention too much, which would
> * halt forward progress.
> */
> -size_t sgx_reclaim_epc_pages(size_t nr_to_scan, bool ignore_age)
> +size_t sgx_reclaim_epc_pages(size_t nr_to_scan, bool ignore_age,
> + struct sgx_epc_cgroup *epc_cg)
> {
> struct sgx_backing backing[SGX_NR_TO_SCAN_MAX];
> struct sgx_epc_page *epc_page, *tmp;
> @@ -355,7 +361,15 @@ size_t sgx_reclaim_epc_pages(size_t nr_to_scan, bool ignore_age)
> LIST_HEAD(iso);
> size_t ret, i;
>
> - sgx_isolate_epc_pages(&sgx_global_lru, nr_to_scan, &iso);
> + /*
> + * If a specific cgroup is not being targeted, take from the global
> + * list first, even when cgroups are enabled. If there are
> + * pages on the global LRU then they should get reclaimed asap.
> + */
> + if (!IS_ENABLED(CONFIG_CGROUP_SGX_EPC) || !epc_cg)
> + sgx_isolate_epc_pages(&sgx_global_lru, &nr_to_scan, &iso);
> +
> + sgx_epc_cgroup_isolate_pages(epc_cg, &nr_to_scan, &iso);
(I wish such code can be somehow moved to the earlier patches, so that we can
get early idea that how sgx_reclaim_epc_pages() is supposed to be used.)
So here when we are not targeting a specific EPC cgroup, we always reclaim from
the global list first, ...
[...]
>
> if (list_empty(&iso))
> return 0;
> @@ -423,7 +437,7 @@ static bool sgx_should_reclaim(unsigned long watermark)
> void sgx_reclaim_direct(void)
> {
> if (sgx_should_reclaim(SGX_NR_LOW_PAGES))
> - sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false);
> + sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false, NULL);
... and we always try to reclaim the global list first when directly reclaim is
desired, even the enclave is within some EPC cgroup. ...
> }
>
> static int ksgxd(void *p)
> @@ -446,7 +460,7 @@ static int ksgxd(void *p)
> sgx_should_reclaim(SGX_NR_HIGH_PAGES));
>
> if (sgx_should_reclaim(SGX_NR_HIGH_PAGES))
> - sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false);
> + sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false, NULL);
... and in ksgxd() as well, which I guess is somehow acceptable. ...
>
> cond_resched();
> }
> @@ -600,6 +614,11 @@ int sgx_drop_epc_page(struct sgx_epc_page *page)
> struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim)
> {
> struct sgx_epc_page *page;
> + struct sgx_epc_cgroup *epc_cg;
> +
> + epc_cg = sgx_epc_cgroup_try_charge(reclaim);
> + if (IS_ERR(epc_cg))
> + return ERR_CAST(epc_cg);
>
> for ( ; ; ) {
> page = __sgx_alloc_epc_page();
> @@ -608,8 +627,10 @@ struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim)
> break;
> }
>
> - if (!sgx_can_reclaim())
> - return ERR_PTR(-ENOMEM);
> + if (!sgx_can_reclaim()) {
> + page = ERR_PTR(-ENOMEM);
> + break;
> + }
>
> if (!reclaim) {
> page = ERR_PTR(-EBUSY);
> @@ -621,10 +642,17 @@ struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim)
> break;
> }
>
> - sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false);
> + sgx_reclaim_epc_pages(SGX_NR_TO_SCAN, false, NULL);
... and when an EPC page is allocated, no matter whether the EPC page belongs to
any cgroup or not.
When we are allocating EPC page for one enclave, if that enclave belongs to some
cgroup, is it more reasonable to reclaim EPC pages from it's own group (and the
children under it)?
You already got the current EPC cgroup at the beginning of sgx_alloc_epc_page()
when you want to charge the EPC allocation.
> cond_resched();
> }
>
next prev parent reply other threads:[~2023-10-10 0:26 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 3:06 [PATCH v5 00/18] Add Cgroup support for SGX EPC memory Haitao Huang
2023-09-23 3:06 ` [PATCH v5 03/18] x86/sgx: Add sgx_epc_lru_lists to encapsulate LRU lists Haitao Huang
[not found] ` <20230923030657.16148-1-haitao.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-09-23 3:06 ` [PATCH v5 01/18] cgroup/misc: Add per resource callbacks for CSS events Haitao Huang
[not found] ` <20230923030657.16148-2-haitao.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-09-25 17:09 ` Jarkko Sakkinen
2023-09-25 17:09 ` Jarkko Sakkinen
2023-09-26 3:04 ` Haitao Huang
[not found] ` <op.2buytfetwjvjmi-yDQzE4XY+yVaPPhiJ6yCxLKMmGWinSIL2HeeBUIffwg@public.gmane.org>
2023-09-26 13:10 ` Jarkko Sakkinen
2023-09-26 13:10 ` Jarkko Sakkinen
2023-09-26 13:13 ` Jarkko Sakkinen
2023-09-26 13:13 ` Jarkko Sakkinen
2023-09-27 1:56 ` Haitao Huang
2023-10-02 22:47 ` Jarkko Sakkinen
2023-10-02 22:55 ` Jarkko Sakkinen
2023-10-04 15:45 ` Haitao Huang
2023-10-04 17:18 ` Tejun Heo
2023-09-27 9:20 ` Huang, Kai
2023-10-03 14:29 ` Haitao Huang
2023-10-17 18:55 ` Michal Koutný
2023-09-23 3:06 ` [PATCH v5 02/18] cgroup/misc: Add SGX EPC resource type and export APIs for SGX driver Haitao Huang
[not found] ` <20230923030657.16148-3-haitao.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-09-25 18:50 ` Tejun Heo
2023-09-25 18:50 ` Tejun Heo
2023-09-28 3:59 ` Huang, Kai
2023-10-03 7:00 ` Haitao Huang
2023-10-03 19:33 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 04/18] x86/sgx: Use sgx_epc_lru_lists for existing active page list Haitao Huang
2023-09-23 3:06 ` [PATCH v5 05/18] x86/sgx: Store reclaimable EPC pages in sgx_epc_lru_lists Haitao Huang
2023-09-27 10:14 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 06/18] x86/sgx: Introduce EPC page states Haitao Huang
[not found] ` <20230923030657.16148-7-haitao.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-09-25 17:11 ` Jarkko Sakkinen
2023-09-25 17:11 ` Jarkko Sakkinen
2023-09-27 10:28 ` Huang, Kai
2023-10-03 4:49 ` Haitao Huang
2023-10-03 20:03 ` Huang, Kai
2023-10-04 15:24 ` Haitao Huang
2023-10-04 21:05 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 07/18] x86/sgx: Introduce RECLAIM_IN_PROGRESS state Haitao Huang
2023-09-25 17:13 ` Jarkko Sakkinen
2023-09-25 17:13 ` Jarkko Sakkinen
2023-09-27 10:42 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 08/18] x86/sgx: Use a list to track to-be-reclaimed pages Haitao Huang
2023-09-28 9:28 ` Huang, Kai
2023-10-03 5:09 ` Haitao Huang
2023-09-23 3:06 ` [PATCH v5 09/18] x86/sgx: Store struct sgx_encl when allocating new VA pages Haitao Huang
2023-09-27 11:14 ` Huang, Kai
2023-09-27 15:35 ` Haitao Huang
2023-09-27 21:21 ` Huang, Kai
2023-09-29 15:06 ` Haitao Huang
2023-10-02 11:05 ` Huang, Kai
2023-09-27 11:35 ` Huang, Kai
2023-10-03 6:45 ` Haitao Huang
2023-10-03 20:07 ` Huang, Kai
2023-10-04 15:03 ` Haitao Huang
2023-10-04 21:13 ` Huang, Kai
2023-10-05 4:22 ` Haitao Huang
2023-10-05 6:49 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 10/18] x86/sgx: Add EPC page flags to identify owner types Haitao Huang
2023-09-23 3:06 ` [PATCH v5 11/18] x86/sgx: store unreclaimable pages in LRU lists Haitao Huang
2023-09-27 11:57 ` Huang, Kai
2023-10-03 5:42 ` Haitao Huang
2023-09-28 9:41 ` Huang, Kai
2023-10-03 5:15 ` Haitao Huang
2023-10-03 20:12 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 12/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC Haitao Huang
2023-10-09 23:45 ` Huang, Kai
2023-10-10 0:23 ` Sean Christopherson
2023-10-10 0:50 ` Huang, Kai
2023-10-10 1:34 ` Huang, Kai
2023-10-10 16:49 ` Haitao Huang
2023-10-11 0:51 ` Huang, Kai
2023-10-12 13:27 ` Haitao Huang
2023-10-16 10:57 ` Huang, Kai
2023-10-16 19:52 ` Haitao Huang
2023-10-16 21:09 ` Huang, Kai
2023-10-17 0:10 ` Haitao Huang
2023-10-17 1:34 ` Huang, Kai
2023-10-17 12:58 ` Haitao Huang
2023-10-17 18:54 ` Michal Koutný
2023-10-17 19:13 ` Michal Koutný
2023-10-18 4:39 ` Haitao Huang
2023-10-18 4:37 ` Haitao Huang
2023-10-18 13:55 ` Dave Hansen
2023-10-18 15:26 ` Haitao Huang
2023-10-18 15:37 ` Dave Hansen
2023-10-18 15:52 ` Michal Koutný
2023-10-18 16:25 ` Haitao Huang
2023-10-16 21:32 ` Sean Christopherson
2023-10-17 0:09 ` Haitao Huang
2023-10-17 15:43 ` Sean Christopherson
2023-10-17 11:49 ` Mikko Ylinen
2023-10-11 1:14 ` Huang, Kai
2023-10-16 11:02 ` Huang, Kai
2023-10-10 1:42 ` Haitao Huang
2023-10-10 2:23 ` Huang, Kai
2023-10-10 13:26 ` Haitao Huang
2023-10-11 0:01 ` Sean Christopherson
2023-10-11 15:02 ` Haitao Huang
2023-10-10 1:04 ` Haitao Huang
2023-10-10 1:18 ` Huang, Kai
2023-10-10 1:38 ` Haitao Huang
2023-10-10 2:12 ` Huang, Kai
2023-10-10 17:05 ` Haitao Huang
2023-10-11 0:31 ` Huang, Kai
2023-10-11 16:04 ` Haitao Huang
2023-09-23 3:06 ` [PATCH v5 13/18] x86/sgx: Expose sgx_reclaim_pages() for use by EPC cgroup Haitao Huang
2023-10-05 12:24 ` Huang, Kai
2023-10-05 19:23 ` Haitao Huang
2023-10-05 20:25 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 14/18] x86/sgx: Add helper to grab pages from an arbitrary EPC LRU Haitao Huang
2023-09-23 3:06 ` [PATCH v5 15/18] x86/sgx: Prepare for multiple LRUs Haitao Huang
2023-10-05 12:30 ` Huang, Kai
2023-10-05 19:33 ` Haitao Huang
2023-10-05 20:38 ` Huang, Kai
2023-09-23 3:06 ` [PATCH v5 16/18] x86/sgx: Limit process EPC usage with misc cgroup controller Haitao Huang
[not found] ` <20230923030657.16148-17-haitao.huang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-09-25 17:15 ` Jarkko Sakkinen
2023-09-25 17:15 ` Jarkko Sakkinen
2023-10-05 21:01 ` Huang, Kai
2023-10-10 0:12 ` Huang, Kai
2023-10-10 0:16 ` Huang, Kai
2023-10-10 0:26 ` Huang, Kai [this message]
2023-10-22 18:26 ` Haitao Huang
2023-10-10 9:19 ` Huang, Kai
2023-10-10 9:32 ` Huang, Kai
2023-10-17 18:54 ` Michal Koutný
2023-10-19 16:05 ` Haitao Huang
2023-09-23 3:06 ` [PATCH v5 17/18] Docs/x86/sgx: Add description for cgroup support Haitao Huang
2023-09-23 3:06 ` [PATCH v5 18/18] selftests/sgx: Add scripts for EPC cgroup testing Haitao Huang
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=0005a998dab64c182c22abc436cbcd36de4240a1.camel@intel.com \
--to=kai.huang@intel.com \
--cc=anakrish@microsoft.com \
--cc=bp@alien8.de \
--cc=cgroups@vger.kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@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=mikko.ylinen@linux.intel.com \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yangjie@microsoft.com \
--cc=zhanb@microsoft.com \
--cc=zhiquan1.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox