From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA329C433E9 for ; Wed, 27 Jan 2021 17:42:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 998FC64D9E for ; Wed, 27 Jan 2021 17:42:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236197AbhA0Rml (ORCPT ); Wed, 27 Jan 2021 12:42:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:45540 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344079AbhA0Rld (ORCPT ); Wed, 27 Jan 2021 12:41:33 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4AFD664DA0; Wed, 27 Jan 2021 17:40:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611769252; bh=A+c4WcG4MCgojmNyR4EPgWEFyx6i6GsXsarr/bqWt68=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YIbnZ6+7cJyCVf922kPwWPaeD4UR9wS0i37zcn40hY/22CgPl+He7EcqlknAsYsp9 1OxKDcH4YN9noy0f6OIM7tVH8O7H4ZBC4AhPMylm6+8qUyfkU4O03JK9bnomWXs2hs +NVh0kAaeq3o5eYirwAXcjtpINuzyI9lG9ifi4LH3+fD4KdkUcqse/EoCKy43/bZZO Tu9wLhT4GaeT6hcNslKpBWE3eVf0EbO8bgwHvpDK/dKWGyONmjnK/jp7qHS9+CdwR/ APlB2xek78ivHBZhb+l28sFk1s/DQYXRCvouxAb7fbrvSTE9FYcjj3Gu5MbsmUlndG gB5Tw3Yf2/2Iw== Date: Wed, 27 Jan 2021 19:40:49 +0200 From: Jarkko Sakkinen To: Tianjia Zhang Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Sean Christopherson , Shuah Khan , x86@kernel.org, linux-sgx@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Jia Zhang Subject: Re: [PATCH v3 3/5] x86/sgx: Optimize the free_cnt count in sgx_epc_section Message-ID: References: <20210124062907.88229-1-tianjia.zhang@linux.alibaba.com> <20210124062907.88229-4-tianjia.zhang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210124062907.88229-4-tianjia.zhang@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I could bet some money that this does not bring any significant performance gain. On Sun, Jan 24, 2021 at 02:29:05PM +0800, Tianjia Zhang wrote: > `section->free_cnt` represents the free page in sgx_epc_section, > which is assigned once after initialization. In fact, just after the > initialization is completed, the pages are in the `init_laundry_list` > list and cannot be allocated. This needs to be recovered by EREMOVE > of function sgx_sanitize_section() before it can be used as a page > that can be allocated. The sgx_sanitize_section() will be called in > the kernel thread ksgxd. > > This patch moves the initialization of `section->free_cnt` from the > initialization function `sgx_setup_epc_section()` to the function > `sgx_sanitize_section()`, and then accumulates the count after the Use single quotes instead of hyphens. > successful execution of EREMOVE. This seems to be more reasonable, > free_cnt will also truly reflect the allocatable free pages in EPC. > > Sined-off-by: Tianjia Zhang > Reviewed-by: Sean Christopherson > --- > arch/x86/kernel/cpu/sgx/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c > index 4465912174fd..e455ec7b3449 100644 > --- a/arch/x86/kernel/cpu/sgx/main.c > +++ b/arch/x86/kernel/cpu/sgx/main.c > @@ -48,6 +48,7 @@ static void sgx_sanitize_section(struct sgx_epc_section *section) > if (!ret) { > spin_lock(§ion->lock); > list_move(&page->list, §ion->page_list); > + section->free_cnt++; > spin_unlock(§ion->lock); Someone can try to allocate a page while sanitize process is in progress. I think it is better to keep critical sections in the form that when you leave from one, the global state is legit. > } else > list_move_tail(&page->list, &dirty); > @@ -643,7 +644,6 @@ static bool __init sgx_setup_epc_section(u64 phys_addr, u64 size, > list_add_tail(§ion->pages[i].list, §ion->init_laundry_list); > } > > - section->free_cnt = nr_pages; > return true; > } > > -- > 2.19.1.3.ge56e4f7 > > /Jarkko