Re: [PATCH v7 04/15] x86/sgx: Implement basic EPC misc cgroup functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed Jan 24, 2024 at 5:29 AM EET, Haitao Huang wrote:
> On Mon, 22 Jan 2024 14:25:53 -0600, Jarkko Sakkinen <jarkko@xxxxxxxxxx>  
> wrote:
>
> > On Mon Jan 22, 2024 at 7:20 PM EET, Haitao Huang wrote:
> >> From: Kristen Carlson Accardi <kristen@xxxxxxxxxxxxxxx>
> >>
> >> SGX Enclave Page Cache (EPC) memory allocations are separate from normal
> >> RAM allocations, and are managed solely by the SGX subsystem. The
> >> existing cgroup memory controller cannot be used to limit or account for
> >> SGX EPC memory, which is a desirable feature in some environments.  For
> >> example, in a Kubernates environment, a user can request certain EPC
> >> quota for a pod but the orchestrator can not enforce the quota to limit
> >> runtime EPC usage of the pod without an EPC cgroup controller.
> >>
> >> Utilize the misc controller [admin-guide/cgroup-v2.rst, 5-9. Misc] to
> >> limit and track EPC allocations per cgroup. Earlier patches have added
> >> the "sgx_epc" resource type in the misc cgroup subsystem. Add basic
> >> support in SGX driver as the "sgx_epc" resource provider:
> >>
> >> - Set "capacity" of EPC by calling misc_cg_set_capacity()
> >> - Update EPC usage counter, "current", by calling charge and uncharge
> >> APIs for EPC allocation and deallocation, respectively.
> >> - Setup sgx_epc resource type specific callbacks, which perform
> >> initialization and cleanup during cgroup allocation and deallocation,
> >> respectively.
> >>
> >> With these changes, the misc cgroup controller enables user to set a  
> >> hard
> >> limit for EPC usage in the "misc.max" interface file. It reports current
> >> usage in "misc.current", the total EPC memory available in
> >> "misc.capacity", and the number of times EPC usage reached the max limit
> >> in "misc.events".
> >>
> >> For now, the EPC cgroup simply blocks additional EPC allocation in
> >> sgx_alloc_epc_page() when the limit is reached. Reclaimable pages are
> >> still tracked in the global active list, only reclaimed by the global
> >> reclaimer when the total free page count is lower than a threshold.
> >>
> >> Later patches will reorganize the tracking and reclamation code in the
> >> global reclaimer and implement per-cgroup tracking and reclaiming.
> >>
> >> Co-developed-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> >> Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> >> Signed-off-by: Kristen Carlson Accardi <kristen@xxxxxxxxxxxxxxx>
> >> Co-developed-by: Haitao Huang <haitao.huang@xxxxxxxxxxxxxxx>
> >> Signed-off-by: Haitao Huang <haitao.huang@xxxxxxxxxxxxxxx>
> >
> > For consistency sake I'd also add co-developed-by for Kristen. This is
> > at least the format suggested by kernel documentation.
> >
> She is the "From Author", so only Signed-off-by is needed for her  
> according to the second example in the doc[1]?

Right but okay then Kristen afaik  be the last sob so only re-ordering
is needed I guess.

>
> Thanks
> Haitao
> [1]https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

BR, Jarkko





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux