On Thu, 2023-10-05 at 14:33 -0500, Haitao Huang wrote:
> On Thu, 05 Oct 2023 07:30:46 -0500, Huang, Kai <kai.huang@xxxxxxxxx> wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > +static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct
> > > sgx_epc_page *epc_page)
> > > +{
> > > + return &sgx_global_lru;
> > > +}
> > > +
> > > +static inline bool sgx_can_reclaim(void)
> > > +{
> > > + return !list_empty(&sgx_global_lru.reclaimable);
> > > +}
> > > +
> >
> > Shouldn't sgx_can_reclaim() also take a 'struct sgx_epc_lru_lists *'?
> >
> > I thought we also need to check whether a cgroup's LRU lists can be
> > reclaimed?
>
> This is only used to check if any pages reclaimable at the top level in
> this file. Later sgx_epc_cgroup_lru_empty(NULL) is used in this function
> to recursively check all cgroups starting from the root.
>
>
This again falls to the "impossible to review unless review a later patch first"
category. This patch says nothing about sgx_can_reclaim() will only be used at
the top level. Even if it does, why cannot it take LRU lists as input?
All this patch says is we need to prepare these functions to suit multiple LRU
lists.
Btw, why sgx_reclaim_epc_pages() doesn't take LRU lists as input either? Is it
possible that it can be called across multiple LRU lists, or across different
lists in one LRU?
Why do we need to find some particular LRU lists by given EPC page?
+static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct sgx_epc_page
*epc_page)
+{
+ return &sgx_global_lru;
+}
+
Maybe it's clear for other people, but to me it sounds some necessary design
background is missing at least.
Please try best to make the patch self-reviewable by justifying all of those.
