lkml.org 
[lkml]   [2024]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8 05/15] x86/sgx: Add sgx_epc_lru_list to encapsulate LRU list
Date
From
On Thu, 01 Feb 2024 17:28:32 -0600, Jarkko Sakkinen <jarkko@kernel.org>  
wrote:

> On Tue Jan 30, 2024 at 4:09 AM EET, Haitao Huang wrote:
>> From: Sean Christopherson <sean.j.christopherson@intel.com>
>>
>> Introduce a data structure to wrap the existing reclaimable list and its
>> spinlock. Each cgroup later will have one instance of this structure to
>> track EPC pages allocated for processes associated with the same cgroup.
>> Just like the global SGX reclaimer (ksgxd), an EPC cgroup reclaims pages
>> from the reclaimable list in this structure when its usage reaches near
>> its limit.
>>
>> Use this structure to encapsulate the LRU list and its lock used by the
>> global reclaimer.
>>
>> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>> Co-developed-by: Kristen Carlson Accardi <kristen@linux.intel.com>
>> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
>> Co-developed-by: Haitao Huang <haitao.huang@linux.intel.com>
>> Signed-off-by: Haitao Huang <haitao.huang@linux.intel.com>
>
> I'd put author as last sob but that said I'm not sure if there is rigid
> rule to do so. Thus not saying must here.
>

The documentation says "the ordering of Signed-off-by: tags should reflect
the chronological history of the patch insofar as possible, regardless of
whether the author is attributed via From: or Co-developed-by:. Notably,
the last Signed-off-by: must always be that of the developer submitting
the patch."

So this should be OK.
[...]
>> struct sgx_epc_page *__sgx_alloc_epc_page(void);
>> void sgx_free_epc_page(struct sgx_epc_page *page);
>>
>
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> BR, Jarkko
>
Thank you!
Haitao

\
 
 \ /
  Last update: 2024-05-27 14:46    [W:0.522 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site