public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Kristen Carlson Accardi <kristen@linux.intel.com>
Cc: dave.hansen@linux.intel.com, tj@kernel.org,
	linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org,
	cgroups@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	zhiquan1.li@intel.com, Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v2 06/18] x86/sgx: Introduce RECLAIM_IN_PROGRESS flag for EPC pages
Date: Thu, 8 Dec 2022 15:46:21 +0000	[thread overview]
Message-ID: <Y5IGzbNxOBkRoaRx@kernel.org> (raw)
In-Reply-To: <20221202183655.3767674-7-kristen@linux.intel.com>

On Fri, Dec 02, 2022 at 10:36:42AM -0800, Kristen Carlson Accardi wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> When selecting pages to be reclaimed from the page pool (sgx_global_lru),
> the list of reclaimable pages is walked, and any page that is both
> reclaimable and not in the process of being freed is added to a list of
> potential candidates to be reclaimed. After that, this separate list is
> further examined and may or may not ultimately be reclaimed. In order
> to prevent this page from being removed from the sgx_epc_lru_lists
> struct in a separate thread by sgx_drop_epc_page(), keep track of
> whether the EPC page is in the middle of being reclaimed with
> the addtion of a RECLAIM_IN_PROGRESS flag, and do not delete the page
> off the LRU in sgx_drop_epc_page() if it has not yet finished being
> reclaimed.
> 
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
> Cc: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kernel/cpu/sgx/main.c | 15 ++++++++++-----
>  arch/x86/kernel/cpu/sgx/sgx.h  |  2 ++
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index ecd7f8e704cc..bad72498b0a7 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -305,13 +305,15 @@ static void __sgx_reclaim_pages(void)
>  
>  		encl_page = epc_page->encl_owner;
>  
> -		if (kref_get_unless_zero(&encl_page->encl->refcount) != 0)
> +		if (kref_get_unless_zero(&encl_page->encl->refcount) != 0) {
> +			epc_page->flags |= SGX_EPC_PAGE_RECLAIM_IN_PROGRESS;
>  			chunk[cnt++] = epc_page;
> -		else
> +		} else {
>  			/* The owner is freeing the page. No need to add the
>  			 * page back to the list of reclaimable pages.
>  			 */
>  			epc_page->flags &= ~SGX_EPC_PAGE_RECLAIMER_TRACKED;
> +		}
>  	}
>  	spin_unlock(&sgx_global_lru.lock);
>  
> @@ -337,6 +339,7 @@ static void __sgx_reclaim_pages(void)
>  
>  skip:
>  		spin_lock(&sgx_global_lru.lock);
> +		epc_page->flags &= ~SGX_EPC_PAGE_RECLAIM_IN_PROGRESS;
>  		sgx_epc_push_reclaimable(&sgx_global_lru, epc_page);
>  		spin_unlock(&sgx_global_lru.lock);
>  
> @@ -360,7 +363,8 @@ static void __sgx_reclaim_pages(void)
>  		sgx_reclaimer_write(epc_page, &backing[i]);
>  
>  		kref_put(&encl_page->encl->refcount, sgx_encl_release);
> -		epc_page->flags &= ~SGX_EPC_PAGE_RECLAIMER_TRACKED;
> +		epc_page->flags &= ~(SGX_EPC_PAGE_RECLAIMER_TRACKED |
> +				     SGX_EPC_PAGE_RECLAIM_IN_PROGRESS);
>  
>  		sgx_free_epc_page(epc_page);
>  	}
> @@ -508,7 +512,8 @@ struct sgx_epc_page *__sgx_alloc_epc_page(void)
>  void sgx_record_epc_page(struct sgx_epc_page *page, unsigned long flags)
>  {
>  	spin_lock(&sgx_global_lru.lock);
> -	WARN_ON(page->flags & SGX_EPC_PAGE_RECLAIMER_TRACKED);
> +	WARN_ON(page->flags & (SGX_EPC_PAGE_RECLAIMER_TRACKED |
> +			       SGX_EPC_PAGE_RECLAIM_IN_PROGRESS));
>  	page->flags |= flags;
>  	if (flags & SGX_EPC_PAGE_RECLAIMER_TRACKED)
>  		sgx_epc_push_reclaimable(&sgx_global_lru, page);
> @@ -532,7 +537,7 @@ int sgx_drop_epc_page(struct sgx_epc_page *page)
>  	spin_lock(&sgx_global_lru.lock);
>  	if (page->flags & SGX_EPC_PAGE_RECLAIMER_TRACKED) {
>  		/* The page is being reclaimed. */
> -		if (list_empty(&page->list)) {
> +		if (page->flags & SGX_EPC_PAGE_RECLAIM_IN_PROGRESS) {
>  			spin_unlock(&sgx_global_lru.lock);
>  			return -EBUSY;
>  		}
> diff --git a/arch/x86/kernel/cpu/sgx/sgx.h b/arch/x86/kernel/cpu/sgx/sgx.h
> index ba4338b7303f..37d66bc6ca27 100644
> --- a/arch/x86/kernel/cpu/sgx/sgx.h
> +++ b/arch/x86/kernel/cpu/sgx/sgx.h
> @@ -30,6 +30,8 @@
>  #define SGX_EPC_PAGE_IS_FREE		BIT(1)
>  /* Pages allocated for KVM guest */
>  #define SGX_EPC_PAGE_KVM_GUEST		BIT(2)
> +/* page flag to indicate reclaim is in progress */
> +#define SGX_EPC_PAGE_RECLAIM_IN_PROGRESS BIT(3)
>  
>  struct sgx_epc_page {
>  	unsigned int section;
> -- 
> 2.38.1
> 

I would create:

enum sgx_epc_state {    
        SGX_EPC_STATE_READY = 0,
        SGX_EPC_STATE_RECLAIMER_TRACKED = 1,
        SGX_EPC_STATE_RECLAIM_IN_PROGRESS = 2,
};

I.e. not a bitmask because page should have only one state at
a time for any of this to make any sense. We have an FSM,
right?

And then allocate 2 upper bits to store this information from
flags.

And probably would make sense to have inline helper functions
to setting and getting the state that does the bitshifting and
masking shenanigangs.

This would be a patch prepending this.

In this patch you should then describe in the context of FSM
how EPC page moves between these states. With that knowledge
we can then reflect the actual code change.

The point is not to get right but more like a mindset that we
can discuss right or wrong in thee first place so just do your
best but don't stress too much.

BR, Jarkko

  parent reply	other threads:[~2022-12-08 15:46 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 18:36 [PATCH v2 00/18] Add Cgroup support for SGX EPC memory Kristen Carlson Accardi
2022-12-02 18:36 ` [PATCH v2 01/18] x86/sgx: Call cond_resched() at the end of sgx_reclaim_pages() Kristen Carlson Accardi
2022-12-02 21:33   ` Dave Hansen
2022-12-02 21:37     ` Kristen Carlson Accardi
2022-12-02 21:45       ` Dave Hansen
2022-12-02 22:17         ` Kristen Carlson Accardi
2022-12-02 22:37           ` Dave Hansen
2022-12-02 18:36 ` [PATCH v2 02/18] x86/sgx: Store struct sgx_encl when allocating new VA pages Kristen Carlson Accardi
2022-12-02 21:35   ` Dave Hansen
2022-12-02 21:40     ` Kristen Carlson Accardi
2022-12-02 21:48       ` Dave Hansen
2022-12-02 22:35         ` Sean Christopherson
2022-12-02 22:47           ` Dave Hansen
2022-12-02 22:49             ` Sean Christopherson
2022-12-02 18:36 ` [PATCH v2 03/18] x86/sgx: Add 'struct sgx_epc_lru_lists' to encapsulate lru list(s) Kristen Carlson Accardi
2022-12-02 21:39   ` Dave Hansen
2022-12-08 15:31   ` Jarkko Sakkinen
2022-12-08 18:03     ` Kristen Carlson Accardi
2022-12-02 18:36 ` [PATCH v2 04/18] x86/sgx: Use sgx_epc_lru_lists for existing active page list Kristen Carlson Accardi
2022-12-02 21:43   ` Dave Hansen
2022-12-02 21:51     ` Kristen Carlson Accardi
2022-12-02 22:10       ` Dave Hansen
2022-12-02 18:36 ` [PATCH v2 05/18] x86/sgx: Track epc pages on reclaimable or unreclaimable lists Kristen Carlson Accardi
2022-12-02 22:13   ` Dave Hansen
2022-12-02 22:28     ` Sean Christopherson
2022-12-02 18:36 ` [PATCH v2 06/18] x86/sgx: Introduce RECLAIM_IN_PROGRESS flag for EPC pages Kristen Carlson Accardi
2022-12-02 22:15   ` Dave Hansen
2022-12-08 15:46   ` Jarkko Sakkinen [this message]
2022-12-08 18:13     ` Kristen Carlson Accardi
2022-12-02 18:36 ` [PATCH v2 07/18] x86/sgx: Use a list to track to-be-reclaimed pages during reclaim Kristen Carlson Accardi
2022-12-02 22:33   ` Dave Hansen
2022-12-05 16:33     ` Kristen Carlson Accardi
2022-12-05 17:03       ` Dave Hansen
2022-12-05 18:25         ` Kristen Carlson Accardi
2022-12-02 18:36 ` [PATCH v2 08/18] x86/sgx: Allow reclaiming up to 32 pages, but scan 16 by default Kristen Carlson Accardi
2022-12-08  9:26   ` Jarkko Sakkinen
2022-12-08  9:27     ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 09/18] x86/sgx: Return the number of EPC pages that were successfully reclaimed Kristen Carlson Accardi
2022-12-08  9:30   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 10/18] x86/sgx: Add option to ignore age of page during EPC reclaim Kristen Carlson Accardi
2022-12-08  9:37   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 11/18] x86/sgx: Prepare for multiple LRUs Kristen Carlson Accardi
2022-12-08  9:42   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 12/18] x86/sgx: Expose sgx_reclaim_pages() for use by EPC cgroup Kristen Carlson Accardi
2022-12-08  9:46   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 13/18] x86/sgx: Add helper to grab pages from an arbitrary EPC LRU Kristen Carlson Accardi
2022-12-08  9:56   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 14/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC Kristen Carlson Accardi
2022-12-08 15:21   ` Jarkko Sakkinen
2022-12-09 16:05     ` Kristen Carlson Accardi
2022-12-09 16:22       ` Dave Hansen
2022-12-12 18:09         ` Sean Christopherson
2022-12-26 20:43           ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 15/18] cgroup/misc: Add per resource callbacks for css events Kristen Carlson Accardi
2022-12-08 14:53   ` Jarkko Sakkinen
2022-12-08 15:15     ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 16/18] cgroup/misc: Prepare for SGX usage Kristen Carlson Accardi
2022-12-08 15:23   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 17/18] x86/sgx: Add support for misc cgroup controller Kristen Carlson Accardi
2022-12-08 15:30   ` Jarkko Sakkinen
2022-12-02 18:36 ` [PATCH v2 18/18] Docs/x86/sgx: Add description for cgroup support Kristen Carlson Accardi
2023-04-03 21:26 ` [EXTERNAL] [PATCH v2 00/18] Add Cgroup support for SGX EPC memory Anand Krishnamoorthi
2023-04-13 18:49   ` Anand Krishnamoorthi
2023-04-18 16:44     ` Mikko Ylinen
2023-04-27 16:53       ` Anand Krishnamoorthi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y5IGzbNxOBkRoaRx@kernel.org \
    --to=jarkko@kernel.org \
    --cc=bp@alien8.de \
    --cc=cgroups@vger.kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=x86@kernel.org \
    --cc=zhiquan1.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox