From: "Huang, Kai" <kai.huang@intel.com>
To: Haitao Huang <haitao.huang@linux.intel.com>, <jarkko@kernel.org>,
<dave.hansen@linux.intel.com>, <tj@kernel.org>,
<mkoutny@suse.com>, <linux-kernel@vger.kernel.org>,
<linux-sgx@vger.kernel.org>, <x86@kernel.org>,
<cgroups@vger.kernel.org>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <hpa@zytor.com>,
<sohil.mehta@intel.com>, <tim.c.chen@linux.intel.com>
Cc: <zhiquan1.li@intel.com>, <kristen@linux.intel.com>,
<seanjc@google.com>, <zhanb@microsoft.com>,
<anakrish@microsoft.com>, <mikko.ylinen@linux.intel.com>,
<yangjie@microsoft.com>, <chrisyan@microsoft.com>
Subject: Re: [PATCH v12 09/14] x86/sgx: Implement async reclamation for cgroup
Date: Fri, 19 Apr 2024 13:32:14 +1200 [thread overview]
Message-ID: <640866c5-9fe0-4f7b-a459-7a685dbe4092@intel.com> (raw)
In-Reply-To: <20240416032011.58578-10-haitao.huang@linux.intel.com>
On 16/04/2024 3:20 pm, Haitao Huang wrote:
> From: Kristen Carlson Accardi <kristen@linux.intel.com>
>
> In cases EPC pages need be allocated during a page fault and the cgroup
> usage is near its limit, an asynchronous reclamation needs be triggered
> to avoid blocking the page fault handling.
>
> Create a workqueue, corresponding work item and function definitions
> for EPC cgroup to support the asynchronous reclamation.
>
> In case the workqueue allocation is failed during init, disable cgroup.
It's fine and reasonable to disable (SGX EPC) cgroup. The problem is
"exactly what does this mean" isn't quite clear.
Given SGX EPC is just one type of MISC cgroup resources, we cannot just
disable MISC cgroup as a whole.
So, the first interpretation is we treat the entire MISC_CG_RES_SGX
resource type doesn't exist, that is, we just don't show control files
in the file system, and all EPC pages are tracked in the global list.
But it might be not straightforward to implement in the SGX driver,
i.e., we might need to do more MISC cgroup core code change to make it
being able to support disable particular resource at runtime -- I need
to double check.
So if that is not something worth to do, we will still need to live with
the fact that, the user is still able to create SGX cgroup in the
hierarchy and see those control files, and being able to read/write them.
The second interpretation I suppose is, although the SGX cgroup is still
seen as supported in userspace, in kernel we just treat it doesn't exist.
Specifically, that means: 1) we always return the root SGX cgroup for
any EPC page when allocating a new one; 2) as a result, we still track
all EPC pages in a single global list.
But from the code below ...
> static int __sgx_cgroup_try_charge(struct sgx_cgroup *epc_cg)
> {
> if (!misc_cg_try_charge(MISC_CG_RES_SGX_EPC, epc_cg->cg, PAGE_SIZE))
> @@ -117,19 +226,28 @@ int sgx_cgroup_try_charge(struct sgx_cgroup *sgx_cg, enum sgx_reclaim reclaim)
> {
> int ret;
>
> + /* cgroup disabled due to wq allocation failure during sgx_cgroup_init(). */
> + if (!sgx_cg_wq)
> + return 0;
> +
..., IIUC you choose a (third) solution that is even one more step back:
It just makes try_charge() always succeed, but EPC pages are still
managed in the "per-cgroup" list.
But this solution, AFAICT, doesn't work. The reason is when you fail to
allocate EPC page you will do the global reclaim, but now the global
list is empty.
Am I missing anything?
So my thinking is, we have two options:
1) Modify the MISC cgroup core code to allow the kernel to disable one
particular resource. It shouldn't be hard, e.g., we can add a
'disabled' flag to the 'struct misc_res'.
Hmm.. wait, after checking, the MISC cgroup won't show any control files
if the "capacity" of the resource is 0:
"
* Miscellaneous resources capacity for the entire machine. 0 capacity
* means resource is not initialized or not present in the host.
"
So I really suppose we should go with this route, i.e., by just setting
the EPC capacity to 0?
Note misc_cg_try_charge() will fail if capacity is 0, but we can make it
return success by explicitly check whether SGX cgroup is disabled by
using a helper, e.g., sgx_cgroup_disabled().
And you always return the root SGX cgroup in sgx_get_current_cg() when
sgx_cgroup_disabled() is true.
And in sgx_reclaim_pages_global(), you do something like:
static void sgx_reclaim_pages_global(..)
{
#ifdef CONFIG_CGROUP_MISC
if (sgx_cgroup_disabled())
sgx_reclaim_pages(&sgx_root_cg.lru);
else
sgx_cgroup_reclaim_pages(misc_cg_root());
#else
sgx_reclaim_pages(&sgx_global_list);
#endif
}
I am perhaps missing some other spots too but you got the idea.
At last, after typing those, I believe we should have a separate patch
to handle disable SGX cgroup at initialization time. And you can even
put this patch _somewhere_ after the patch
"x86/sgx: Implement basic EPC misc cgroup functionality"
and before this patch.
It makes sense to have such patch anyway, because with it we can easily
to add a kernel command line 'sgx_cgroup=disabled" if the user wants it
disabled (when someone has such requirement in the future).
next prev parent reply other threads:[~2024-04-19 1:32 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 3:19 [PATCH v12 00/14] Add Cgroup support for SGX EPC memory Haitao Huang
2024-04-16 3:19 ` [PATCH v12 01/14] x86/sgx: Replace boolean parameters with enums Haitao Huang
2024-04-16 3:19 ` [PATCH v12 02/14] cgroup/misc: Add per resource callbacks for CSS events Haitao Huang
2024-04-16 3:20 ` [PATCH v12 03/14] cgroup/misc: Export APIs for SGX driver Haitao Huang
2024-04-16 3:20 ` [PATCH v12 04/14] cgroup/misc: Add SGX EPC resource type Haitao Huang
2024-04-16 3:20 ` [PATCH v12 05/14] x86/sgx: Implement basic EPC misc cgroup functionality Haitao Huang
2024-04-16 13:22 ` Huang, Kai
2024-04-18 22:41 ` Haitao Huang
2024-04-18 23:29 ` Huang, Kai
2024-04-19 18:15 ` Haitao Huang
2024-04-19 22:21 ` Huang, Kai
2024-04-16 22:23 ` Haitao Huang
2024-04-16 3:20 ` [PATCH v12 06/14] x86/sgx: Add sgx_epc_lru_list to encapsulate LRU list Haitao Huang
2024-04-16 3:20 ` [PATCH v12 07/14] x86/sgx: Abstract tracking reclaimable pages in LRU Haitao Huang
2024-04-16 14:07 ` Huang, Kai
2024-04-16 22:48 ` Haitao Huang
2024-04-16 3:20 ` [PATCH v12 08/14] x86/sgx: Add basic EPC reclamation flow for cgroup Haitao Huang
2024-04-17 23:51 ` Huang, Kai
2024-04-23 15:53 ` Haitao Huang
2024-04-16 3:20 ` [PATCH v12 09/14] x86/sgx: Implement async reclamation " Haitao Huang
2024-04-19 1:32 ` Huang, Kai [this message]
2024-04-19 18:55 ` Haitao Huang
2024-04-19 22:44 ` Huang, Kai
2024-04-20 1:14 ` Haitao Huang
2024-04-22 0:22 ` Huang, Kai
2024-04-22 16:17 ` Haitao Huang
2024-04-22 22:16 ` Huang, Kai
2024-04-23 13:08 ` Haitao Huang
2024-04-23 14:19 ` Huang, Kai
2024-04-23 15:30 ` Haitao Huang
2024-04-23 22:13 ` Huang, Kai
2024-04-24 0:26 ` Haitao Huang
2024-04-24 2:13 ` Huang, Kai
2024-04-16 3:20 ` [PATCH v12 10/14] x86/sgx: Charge mem_cgroup for per-cgroup reclamation Haitao Huang
2024-04-23 7:21 ` Huang, Kai
2024-04-16 3:20 ` [PATCH v12 11/14] x86/sgx: Abstract check for global reclaimable pages Haitao Huang
2024-04-16 3:20 ` [PATCH v12 12/14] x86/sgx: Turn on per-cgroup EPC reclamation Haitao Huang
2024-04-29 10:49 ` Huang, Kai
2024-04-29 16:05 ` Haitao Huang
2024-04-29 22:18 ` Huang, Kai
2024-04-30 1:31 ` Haitao Huang
2024-04-16 3:20 ` [PATCH v12 13/14] Docs/x86/sgx: Add description for cgroup support Haitao Huang
2024-04-21 7:18 ` Bagas Sanjaya
2024-04-23 7:29 ` Huang, Kai
2024-04-16 3:20 ` [PATCH v12 14/14] selftests/sgx: Add scripts for EPC cgroup testing Haitao Huang
2024-04-16 5:16 ` Haitao Huang
2024-04-16 5:42 ` Huang, Kai
2024-04-16 14:15 ` Jarkko Sakkinen
2024-04-26 14:28 ` Dave Hansen
2024-04-28 22:03 ` Jarkko Sakkinen
2024-04-29 16:18 ` Haitao Huang
2024-04-29 16:43 ` Jarkko Sakkinen
2024-04-29 17:14 ` Haitao Huang
2024-04-16 15:00 ` Haitao Huang
2024-04-16 14:05 ` Jarkko Sakkinen
2024-04-16 14:10 ` Jarkko Sakkinen
2024-04-16 14:54 ` Haitao Huang
2024-04-16 16:08 ` Jarkko Sakkinen
2024-04-16 22:04 ` Haitao Huang
2024-04-16 22:21 ` Haitao Huang
2024-04-17 3:05 ` Haitao Huang
2024-04-17 22:46 ` Jarkko Sakkinen
2024-04-24 19:42 ` Haitao Huang
2024-04-25 4:51 ` 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=640866c5-9fe0-4f7b-a459-7a685dbe4092@intel.com \
--to=kai.huang@intel.com \
--cc=anakrish@microsoft.com \
--cc=bp@alien8.de \
--cc=cgroups@vger.kernel.org \
--cc=chrisyan@microsoft.com \
--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=mkoutny@suse.com \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--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
all inboxes | Powered by JetHome®