From mboxrd@z Thu Jan 1 00:00:00 1970 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 137FC1C9EC8; Tue, 27 Aug 2024 18:16:34 +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=1724782595; cv=none; b=GAqqDd6uEn2rxU/wgAoN039XwMqq84Wg0nPCoXTfuQHso0D0hv3uQidjTB6YlRAWGHvDI+FCXquT9Odh5Rh+f2PvnraKg1HkZRX7JhMpbSrci2jJNcQMpgMsikZU1xhKyBmdP/JSFHTyx87zBcp/QNnq8PElhhyHc/+SNXnEQyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724782595; c=relaxed/simple; bh=1GxHEPXrVAe6OIAhEpqeV+67xfNW4gro/ZqKgd5SEgo=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=TY0hp2ULW6675lxp7uRiT0ugqUQerbVQ8jm4HFOUHxCL7UdCIeUqEVmFFE90UjX5hT5CelKJDpd1Y3L3VaIq/VHK8/gG0dqtienJ7UbqwKxV+nD088wIOv11li5lHVGxsMH3WiZpJX+EC2UHa8jjF8u8mNr69v4WPeqlcVWZOvo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FakWBL8F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FakWBL8F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4707BC567C2; Tue, 27 Aug 2024 18:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724782594; bh=1GxHEPXrVAe6OIAhEpqeV+67xfNW4gro/ZqKgd5SEgo=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=FakWBL8Ff+52pY0kGshsQMNywCQSI+TbZ1IvN5XC0voIOWjz9wFOtbWJHItSwyKAM 49aVNjN/LVFFbZqhevLCwRhhXN7kjtAQhHjCdUPzNVI6IwReFFwbPwhP6/BvCyGlo1 Gg/GpUSiOVy5/wroNA0tp/rcW90+47tiWop8rZstDh5xephA7BzGh9dDY3n+50oacu rLrg+XpMyh32z4QO2N4Sf/Cdf4pryYbdhzDW/JaCEu++gN+8cizAl8h/5IO4le+R9e vMtLeconBLjwsteU6N71z8N9s5xuLgzLu0Oo3GET12SJYfx0xs6SAWSzRCvq2AdHmN GUbDkhPUU5UDw== Precedence: bulk X-Mailing-List: cgroups@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: Tue, 27 Aug 2024 21:16:31 +0300 Message-Id: To: "Haitao Huang" , , , , , , , , , , , , , , , Cc: , , , , , , , Subject: Re: [PATCH v16 12/16] x86/sgx: Revise global reclamation for EPC cgroups From: "Jarkko Sakkinen" X-Mailer: aerc 0.17.0 References: <20240821015404.6038-1-haitao.huang@linux.intel.com> <20240821015404.6038-13-haitao.huang@linux.intel.com> In-Reply-To: <20240821015404.6038-13-haitao.huang@linux.intel.com> On Wed Aug 21, 2024 at 4:54 AM EEST, Haitao Huang wrote: > With EPC cgroups, the global reclamation function, > sgx_reclaim_pages_global(), can no longer apply to the global LRU as > pages are now in per-cgroup LRUs. > > Create a wrapper, sgx_cgroup_reclaim_global() to invoke > sgx_cgroup_reclaim_pages() passing in the root cgroup. Call this wrapper > from sgx_reclaim_pages_global() when cgroup is enabled. The wrapper will > scan and attempt to reclaim SGX_NR_TO_SCAN pages just like the current > global reclaim. > > Note this simple implementation doesn't _exactly_ mimic the current > global EPC reclaim (which always tries to do the actual reclaim in batch > of SGX_NR_TO_SCAN pages): in rare cases when LRUs have less than > SGX_NR_TO_SCAN reclaimable pages, the actual reclaim of EPC pages will > be split into smaller batches _across_ multiple LRUs with each being > smaller than SGX_NR_TO_SCAN pages. > > A more precise way to mimic the current global EPC reclaim would be to > have a new function to only "scan" (or "isolate") SGX_NR_TO_SCAN pages > _across_ the given EPC cgroup _AND_ its descendants, and then do the > actual reclaim in one batch. But this is unnecessarily complicated at > this stage to address such rare cases. > > Signed-off-by: Haitao Huang Reviewed-by: Jarkko Sakkinen BR, Jarkko