StartHi Kai
On Tue, 20 Feb 2024 03:52:39 -0600, Huang, Kai <kai.huang@xxxxxxxxx> wrote:
[...]
So you introduced the work/workqueue here but there's no place which
actually
queues the work. IMHO you can either:
1) move relevant code change here; or
2) focus on introducing core functions to reclaim certain pages from a
given EPC
cgroup w/o workqueue and introduce the work/workqueue in later patch.
Makes sense?
Starting in v7, I was trying to split the big patch, #10 in v6 as you and
others suggested. My thought process was to put infrastructure needed for
per-cgroup reclaim in the front, then turn on per-cgroup reclaim in [v9
13/15] in the end.
Before that, all reclaimables are tracked in the global LRU so really
there is no "reclaim certain pages from a given EPC cgroup w/o workqueue"
or reclaim through workqueue before that point, as suggested in #2. This
patch puts down the implementation for both flows but neither used yet, as
stated in the commit message.
#1 would force me go back and merge the patches again.
Sorry I feel kind of lost on this whole thing by now. It seems so random
to me. Is there hard rules on this?
I was hoping these statements would help reviewers on the flow of the
patches.
At the end of [v9 04/15]:
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.
At the end of [v9 06/15]:
Next patches will first get the cgroup reclamation flow ready while
keeping pages tracked in the global LRU and reclaimed by ksgxd before we
make the switch in the end for sgx_lru_list() to return per-cgroup
LRU.
At the end of [v9 08/15]:
Both synchronous and asynchronous flows invoke the same top level reclaim
function, and will be triggered later by sgx_epc_cgroup_try_charge()
when usage of the cgroup is at or near its limit.
At the end of [v9 10/15]:
Note at this point, all reclaimable EPC pages are still tracked in the
global LRU and per-cgroup LRUs are empty. So no per-cgroup reclamation
is activated yet.
Thanks
Haitao
