Received: by 2002:a05:7412:2a91:b0:fc:a2b0:25d7 with SMTP id u17csp289782rdh; Tue, 13 Feb 2024 17:52:43 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUF7fGVHr0eorvEIJmHS18bZBpWPT1JsAmO1bKw1IUFoqR/EXv1IsOnJq1pdU2KCLXJ3vqJy8/RQZ7D/SYhvmpvDjPmWu4+8CsRJaritw== X-Google-Smtp-Source: AGHT+IGjvolYwHzl1XiVRdw3bmUcmPpCBReQ76barq+4sjlD8C9JziSDgDAbnZn0v+CnkhLbQYxG X-Received: by 2002:a17:906:408c:b0:a3c:c11b:e260 with SMTP id u12-20020a170906408c00b00a3cc11be260mr609577ejj.68.1707875563342; Tue, 13 Feb 2024 17:52:43 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707875563; cv=pass; d=google.com; s=arc-20160816; b=L16vWXkO7+TGWfzYCFOKAo4L6kgvnPHhqGfSV775WuNracJgrwaOmNDJms0DnJ1y+a XOOLvWKVe+odfui0oTrVL7p1PqWDHaCJaLKd+XOOAFzVSXNdRzqoE2xc6n+RTcS5WHys HmNxVcDZzVzCtEsZzvodz74cySYSwj9YO7K9yJM2cVl+pdnPFgn/++YpAVH1aoP8BUNe g3XxF1FM9QszGxVSzkp1VjT3BxpCEeTSBMdPGj52aDsOUzNUjxs5eFcbMzAi9uukzqhR vhb+Dzdo2dF26UK9hgCTMhvTCoEShMIKAjxZ9624slJ03Kr1ZCnzEKViz/foMRH93Iw3 YmJw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:dkim-signature; bh=l1uyMEgw7i2M/xjXuXm+0X7eutqIYPsDG6Y91Z+G/7s=; fh=ZlHVa4MazRK6UbXE/qKF2BTIYUOuutm9ZOq1fc3woc4=; b=ZfwEzmEuvo44kg9H0T3kSlVZm13oDvyY7rKob8tOTyjFE3hxenGPNWxj1sPE0PYfgz z8zIE7vqCgLyPaVPESqfTCFTleQgASq6Tmsjf6OeMUDSG7ZFHDI2L6rvec9NBm6FB0nD AAIznw42lYwElaGx3Gg0IQS37VSgC86ayFya88EXmQrCuC5VgC6hJnijbos9JSnFvsTV bkfViqYaW8q0ttOv50+swrMnY1igOKMnZdV0qYiuEMjFNuplISAHF06ibGcTFMcnlK9Z G6hL5oeE5/dTEzTD23wwFc+dDs0hytDXREbdxnxh0mAhCFfdC5j89DO7Jk1uCLKigD43 3aig==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MRvM2TND; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-64675-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64675-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=2; AJvYcCVzZ9sJ4esLkiHoz6vmSvu3IUiVLC5nsY6N3m/5IIs0YRoZ+nO/ZGywG7b7t1xkpEsy0LlZZAeI9l7brATY7wb10C53BgnaWmzzD50T7w== Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id d26-20020a17090648da00b00a3d43d35af8si138389ejt.437.2024.02.13.17.52.43 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 17:52:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-64675-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MRvM2TND; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-64675-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-64675-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DF7031F24A81 for ; Wed, 14 Feb 2024 01:52:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4BEA68BFA; Wed, 14 Feb 2024 01:52:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MRvM2TND" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 583672F25; Wed, 14 Feb 2024 01:52:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707875552; cv=none; b=njkoY65EusNqE3s+XvUfmBWZXWgI3E0qe5f91lVKEwXl4UPZl3EmPKIf288AV7/WHx9nw6CnfLd2nLbWgHoS6jrx144BJeUMf/tmHsXAYjeNkRZScexBAt8rPVzvIhxhxzHB/ZwPCw2VdED0Dt/xxV260O8dOJF33vx86iusy6w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707875552; c=relaxed/simple; bh=FYO/Ayy7ax+Dum8m03QRKFc/2rimYYWHD0lN8SmIRKI=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=JdvPHhJ+SNhBLU2lLislYd/El+1jibtZCWotu5rPjWwUhkROyJjPAVe8PZ1qoX73V9TAhUxcX7U/8Ru3/6BCLounmmAO7FCU642Q3jfz7eN24u0whq46tCagzhhytWS3FWSvDmvAcdGaGD4r8XW1IW9zpYyDbotqUKLVrv/3jf4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MRvM2TND; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71571C433F1; Wed, 14 Feb 2024 01:52:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707875551; bh=FYO/Ayy7ax+Dum8m03QRKFc/2rimYYWHD0lN8SmIRKI=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=MRvM2TNDv764T8sEobYFWJAreh9gPPOG4MDc3/ISbZMeqD/o/ciomSn+OhZYlm7yc j0SltrRFxhL5HaFlj42L/xgenQB/8gdDuJJGRq1NuPNR2QMlSf5or/LCqrkniiRnmV CnZAUl+v3eir/gKYQ2b29MUXo5t2UtguF2JqP8ymPKiSEJeyUWsvMSK89crcaRVvq5 gzrfIUHbOrmCtfnlGhJIB23GH72PwRw0kau0qEOWd4ZzBhF5FYVh2WGzpo8Yz0Tavp ODKrCtoFdxK2EjPoPnal5rTfheDNOfRgONRTxRS85QS7dODKUG1HSyuNIWTC1sKW58 2PXXpV6o3xsSQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 14 Feb 2024 03:52:25 +0200 Message-Id: Cc: , , , , , , , Subject: Re: [PATCH v9 10/15] x86/sgx: Add EPC reclamation in cgroup try_charge() From: "Jarkko Sakkinen" To: "Haitao Huang" , , , , , , , , , , , , , X-Mailer: aerc 0.16.0 References: <20240205210638.157741-1-haitao.huang@linux.intel.com> <20240205210638.157741-11-haitao.huang@linux.intel.com> In-Reply-To: On Tue Feb 13, 2024 at 1:15 AM EET, Haitao Huang wrote: > Hi Jarkko > > On Mon, 12 Feb 2024 13:55:46 -0600, Jarkko Sakkinen = =20 > wrote: > > > On Mon Feb 5, 2024 at 11:06 PM EET, Haitao Huang wrote: > >> From: Kristen Carlson Accardi > >> > >> When the EPC usage of a cgroup is near its limit, the cgroup needs to > >> reclaim pages used in the same cgroup to make room for new allocations= . > >> This is analogous to the behavior that the global reclaimer is trigger= ed > >> when the global usage is close to total available EPC. > >> > >> Add a Boolean parameter for sgx_epc_cgroup_try_charge() to indicate > >> whether synchronous reclaim is allowed or not. And trigger the > >> synchronous/asynchronous reclamation flow accordingly. > >> > >> Note at this point, all reclaimable EPC pages are still tracked in the > >> global LRU and per-cgroup LRUs are empty. So no per-cgroup reclamation > >> is activated yet. > >> > >> Co-developed-by: Sean Christopherson > >> Signed-off-by: Sean Christopherson > >> Signed-off-by: Kristen Carlson Accardi > >> Co-developed-by: Haitao Huang > >> Signed-off-by: Haitao Huang > >> --- > >> V7: > >> - Split this out from the big patch, #10 in V6. (Dave, Kai) > >> --- > >> arch/x86/kernel/cpu/sgx/epc_cgroup.c | 26 ++++++++++++++++++++++++-- > >> arch/x86/kernel/cpu/sgx/epc_cgroup.h | 4 ++-- > >> arch/x86/kernel/cpu/sgx/main.c | 2 +- > >> 3 files changed, 27 insertions(+), 5 deletions(-) > >> > >> diff --git a/arch/x86/kernel/cpu/sgx/epc_cgroup.c =20 > >> b/arch/x86/kernel/cpu/sgx/epc_cgroup.c > >> index d399fda2b55e..abf74fdb12b4 100644 > >> --- a/arch/x86/kernel/cpu/sgx/epc_cgroup.c > >> +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c > >> @@ -184,13 +184,35 @@ static void =20 > >> sgx_epc_cgroup_reclaim_work_func(struct work_struct *work) > >> /** > >> * sgx_epc_cgroup_try_charge() - try to charge cgroup for a single EP= C =20 > >> page > >> * @epc_cg: The EPC cgroup to be charged for the page. > >> + * @reclaim: Whether or not synchronous reclaim is allowed > >> * Return: > >> * * %0 - If successfully charged. > >> * * -errno - for failures. > >> */ > >> -int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg) > >> +int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg, bool =20 > >> reclaim) > >> { > >> - return misc_cg_try_charge(MISC_CG_RES_SGX_EPC, epc_cg->cg, PAGE_SIZE= ); > >> + for (;;) { > >> + if (!misc_cg_try_charge(MISC_CG_RES_SGX_EPC, epc_cg->cg, > >> + PAGE_SIZE)) > >> + break; > >> + > >> + if (sgx_epc_cgroup_lru_empty(epc_cg->cg)) > >> + return -ENOMEM; > >> + + if (signal_pending(current)) > >> + return -ERESTARTSYS; > >> + > >> + if (!reclaim) { > >> + queue_work(sgx_epc_cg_wq, &epc_cg->reclaim_work); > >> + return -EBUSY; > >> + } > >> + > >> + if (!sgx_epc_cgroup_reclaim_pages(epc_cg->cg, false)) > >> + /* All pages were too young to reclaim, try again a little later *= / > >> + schedule(); > > > > This will be total pain to backtrack after a while when something > > needs to be changed so there definitely should be inline comments > > addressing each branch condition. > > > > I'd rethink this as: > > > > 1. Create static __sgx_epc_cgroup_try_charge() for addressing single > > iteration with the new "reclaim" parameter. > > 2. Add a new sgx_epc_group_try_charge_reclaim() function. > > > > There's a bit of redundancy with sgx_epc_cgroup_try_charge() and > > sgx_epc_cgroup_try_charge_reclaim() because both have almost the > > same loop calling internal __sgx_epc_cgroup_try_charge() with > > different parameters. That is totally acceptable. > > > > Please also add my suggested-by. > > > > BR, Jarkko > > > > BR, Jarkko > > > For #2: > The only caller of this function, sgx_alloc_epc_page(), has the same =20 > boolean which is passed into this this function. I know. This would be good opportunity to fix that up. Large patch sets should try to make the space for its feature best possible and thus also clean up the code base overally. > If we separate it into sgx_epc_cgroup_try_charge() and =20 > sgx_epc_cgroup_try_charge_reclaim(), then the caller has to have the =20 > if/else branches. So separation here seems not help? Of course it does. It makes the code in that location self-documenting and easier to remember what it does. BR, Jarkko