[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4f5496d2e0ea8edba430e7de7304bdd840616146.camel@intel.com>
Date: Mon, 24 Jul 2023 10:04:48 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "hpa@...or.com" <hpa@...or.com>,
"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
"bp@...en8.de" <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"x86@...nel.org" <x86@...nel.org>,
"haitao.huang@...ux.intel.com" <haitao.huang@...ux.intel.com>,
"tj@...nel.org" <tj@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>
CC: "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Li, Zhiquan1" <zhiquan1.li@...el.com>,
"Christopherson,, Sean" <seanjc@...gle.com>
Subject: Re: [PATCH v3 03/28] x86/sgx: Add 'struct sgx_epc_lru_lists' to
encapsulate lru list(s)
On Mon, 2023-07-17 at 08:23 -0500, Haitao Huang wrote:
> On Mon, 17 Jul 2023 07:45:36 -0500, Jarkko Sakkinen <jarkko@...nel.org>
> wrote:
>
> > On Wed Jul 12, 2023 at 11:01 PM UTC, Haitao Huang wrote:
> > > From: Kristen Carlson Accardi <kristen@...ux.intel.com>
> > >
> > > Introduce a data structure to wrap the existing reclaimable list
> > > and its spinlock in a struct to minimize the code changes needed
> > > to handle multiple LRUs as well as reclaimable and non-reclaimable
> > > lists. The new structure will be used in a following set of patches to
> > > implement SGX EPC cgroups.
Although briefly mentioned in the first patch, it would be better to put more
background about the "reclaimable" and "non-reclaimable" thing here, focusing on
_why_ we need multiple LRUs (presumably you mean two lists: reclaimable and non-
reclaimable).
> > >
> > > The changes to the structure needed for unreclaimable lists will be
> > > added in later patches.
> > >
> > > Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
> > > Signed-off-by: Kristen Carlson Accardi <kristen@...ux.intel.com>
> > > Signed-off-by: Haitao Huang <haitao.huang@...ux.intel.com>
> > > Cc: Sean Christopherson <seanjc@...gle.com>
> > >
> > > V3:
> > > Removed the helper functions and revised commit messages
Please put change history into:
---
change history
---
So it can be stripped away when applying the patch.
> > > ---
> > > arch/x86/kernel/cpu/sgx/sgx.h | 17 +++++++++++++++++
> > > 1 file changed, 17 insertions(+)
> > >
> > > diff --git a/arch/x86/kernel/cpu/sgx/sgx.h
> > > b/arch/x86/kernel/cpu/sgx/sgx.h
> > > index f6e3c5810eef..77fceba73a25 100644
> > > --- a/arch/x86/kernel/cpu/sgx/sgx.h
> > > +++ b/arch/x86/kernel/cpu/sgx/sgx.h
> > > @@ -92,6 +92,23 @@ static inline void *sgx_get_epc_virt_addr(struct
> > > sgx_epc_page *page)
> > > return section->virt_addr + index * PAGE_SIZE;
> > > }
> > >
> > > +/*
> > > + * This data structure wraps a list of reclaimable EPC pages, and a
> > > list of
> > > + * non-reclaimable EPC pages and is used to implement a LRU policy
> > > during
> > > + * reclamation.
> > > + */
I'd prefer to not mention the "non-reclaimable" thing in this patch, but defer
to the one actually introduces the "non-reclaimable" list. Actually, I don't
think we even need this comment, given you have this in the structure:
struct list_head reclaimable;
Which already explains the "reclaimable" list. I suppose the non-reclaimable
list would be named similarly thus need no comment either.
Also, I am wondering why you need to split this out as a separate patch. It
basically does nothing. To me you should just merge this to the next patch,
which actually does what you claimed in the changelog:
Introduce a data structure to wrap the existing reclaimable list andĀ
itsĀ spinlock ...
Then this can be an infrastructure change patch, which doesn't bring any
functional change, to support the non-reclaimable list.
> > > +struct sgx_epc_lru_lists {
> > > + /* Must acquire this lock to access */
> > > + spinlock_t lock;
> >
> > Isn't this self-explanatory, why the inline comment?
>
> I got a warning from the checkpatch script complaining this lock needs
> comments.
I suspected this, so I applied this patch, removed the comment, generated a new
patch, and run checkpatch.pl for it. It didn't report any warning/error in my
testing.
Are you sure you got a warning?
Powered by blists - more mailing lists