Re: [PATCH v9 12/15] x86/sgx: Expose sgx_epc_cgroup_reclaim_pages() for global reclaimer

[Haitao Huang]

On Wed, 21 Feb 2024 05:10:36 -0600, Huang, Kai <kai.huang@xxxxxxxxx> wrote:

> On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> > From: Kristen Carlson Accardi <kristen@xxxxxxxxxxxxxxx>
> >
> > When cgroup is enabled, all reclaimable pages will be tracked in cgroup
> > LRUs. The global reclaimer needs to start reclamation from the root
> > cgroup. Expose the top level cgroup reclamation function so the global
> > reclaimer can reuse it.
> >
> > 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>
> > ---
> > V8:
> > - Remove unneeded breaks in function declarations. (Jarkko)
> >
> > V7:
> > - Split this out from the big patch, #10 in V6. (Dave, Kai)
> > ---
> >  arch/x86/kernel/cpu/sgx/epc_cgroup.c | 2 +-
> >  arch/x86/kernel/cpu/sgx/epc_cgroup.h | 7 +++++++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/cpu/sgx/epc_cgroup.c  
> > b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > index abf74fdb12b4..6e31f8727b8a 100644
> > --- a/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > @@ -96,7 +96,7 @@ bool sgx_epc_cgroup_lru_empty(struct misc_cg *root)
> >   * @indirect:   In ksgxd or EPC cgroup work queue context.
> >   * Return:	Number of pages reclaimed.
> >   */
> > -static unsigned int sgx_epc_cgroup_reclaim_pages(struct misc_cg *root,  
> > bool indirect)
> > +unsigned int sgx_epc_cgroup_reclaim_pages(struct misc_cg *root, bool  
> > indirect)
> >  {
> >  	/*
> >  	 * Attempting to reclaim only a few pages will often fail and is
> > diff --git a/arch/x86/kernel/cpu/sgx/epc_cgroup.h  
> > b/arch/x86/kernel/cpu/sgx/epc_cgroup.h
> > index d061cd807b45..5b3e8e1b8630 100644
> > --- a/arch/x86/kernel/cpu/sgx/epc_cgroup.h
> > +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.h
> > @@ -31,6 +31,11 @@ static inline int sgx_epc_cgroup_try_charge(struct  
> > sgx_epc_cgroup *epc_cg, bool
> >  static inline void sgx_epc_cgroup_uncharge(struct sgx_epc_cgroup  
> > *epc_cg) { }
> >
> >  static inline void sgx_epc_cgroup_init(void) { }
> > +
> > +static inline unsigned int sgx_epc_cgroup_reclaim_pages(struct misc_cg  
> > *root, bool indirect)
> > +{
> > +	return 0;
> > +}
> >  #else
> >  struct sgx_epc_cgroup {
> >  	struct misc_cg *cg;
> > @@ -69,6 +74,8 @@ static inline void sgx_put_epc_cg(struct  
> > sgx_epc_cgroup *epc_cg)
> >  int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg, bool  
> > reclaim);
> >  void sgx_epc_cgroup_uncharge(struct sgx_epc_cgroup *epc_cg);
> >  bool sgx_epc_cgroup_lru_empty(struct misc_cg *root);
> > +unsigned int sgx_epc_cgroup_reclaim_pages(struct misc_cg *root, bool  
> > indirect);
> > +
> >  void sgx_epc_cgroup_init(void);
> >
> >  #endif
>
> I'd just prefer to merge patch such like this to the one that actually  
> uses the
> exposed function.  It's just couple of LOC and we don't deserve to read  
> these
> repeated changelog and move back and forth between patches during review.
IIRC, Jarkko prefers exposing functions first in separate patch. Jarkko,  
right?

Also I found your definition/expectation of self-contained patches is just  
confusing or too constrained at least. I usually review each patch  
separately without back and forth and then review them together to see if  
they all make sense in terms of breakdown. My minimal  expectation is  
that  a patch should not depend on future changes and should not break  
current state of function. and

For this one I thought the idea was you verify if the API exposed make  
sense without looking at how it is used in future. Then when you review  
the usage patch, you see if the usage is reasonable.

I would really hesitate to merge patches at this point unless we all have  
an agreement and have good/strong reasons or there is a hard rule about  
this.

Thanks
Haitao