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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E25A0CD98EE for ; Wed, 11 Oct 2023 16:05:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346956AbjJKQFA (ORCPT ); Wed, 11 Oct 2023 12:05:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232345AbjJKQE6 (ORCPT ); Wed, 11 Oct 2023 12:04:58 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E15079D; Wed, 11 Oct 2023 09:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697040296; x=1728576296; h=to:cc:subject:references:date:mime-version: content-transfer-encoding:from:message-id:in-reply-to; bh=inxQ3IranDcT46Lz+YqsdFYxNjUb8dv9j72WAW4wQlI=; b=m27ZUF+o1gWw7R+i6U3fDCvmJeyvJwQFcnWSUSNK+SoR3wWWPdlDfwai jmb7ppkSV6aH+Np7wroDCs3cdv18De6aWVim8N1v7GXR480/sIv2x61Q4 +DixMdzCB9MLPZ8DWYqHvzWDpCPafd5XCIJ8VZJSdfTs2v343weuu5ttO C+FK1ukKrFAAUqER3+ysnkTgvdo/dbeN0DyZSDKX6i+S936TwNA8oEuk0 W7TCwOd3U6yrCIjgrxkYybmI171qYQUNgqHBPDpVvJTfNqBeV9hhdszwz YWEVKBVqBylnV00HXcJMYk8UWgGp/AVEDxcdVepe3ibL7JmCeng7io+DS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10860"; a="451193463" X-IronPort-AV: E=Sophos;i="6.03,216,1694761200"; d="scan'208";a="451193463" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2023 09:04:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10860"; a="877736596" X-IronPort-AV: E=Sophos;i="6.03,216,1694761200"; d="scan'208";a="877736596" Received: from hhuan26-mobl.amr.corp.intel.com ([10.92.96.100]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 11 Oct 2023 09:04:54 -0700 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Mehta, Sohil" , "linux-sgx@vger.kernel.org" , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "cgroups@vger.kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "tj@kernel.org" , "bp@alien8.de" , "tglx@linutronix.de" , "jarkko@kernel.org" , "linux-kernel@vger.kernel.org" , "Huang, Kai" Cc: "kristen@linux.intel.com" , "yangjie@microsoft.com" , "Li, Zhiquan1" , "Christopherson,, Sean" , "mikko.ylinen@linux.intel.com" , "Zhang, Bo" , "anakrish@microsoft.com" Subject: Re: [PATCH v5 12/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC References: <20230923030657.16148-1-haitao.huang@linux.intel.com> <20230923030657.16148-13-haitao.huang@linux.intel.com> <1b265d0c9dfe17de2782962ed26a99cc9d330138.camel@intel.com> <8593359034d9173be5efd9c055ea782e44fbcdad.camel@intel.com> Date: Wed, 11 Oct 2023 11:04:53 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Haitao Huang" Organization: Intel Message-ID: In-Reply-To: <8593359034d9173be5efd9c055ea782e44fbcdad.camel@intel.com> User-Agent: Opera Mail/1.0 (Win32) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Oct 2023 19:31:19 -0500, Huang, Kai wrote: > On Tue, 2023-10-10 at 12:05 -0500, Haitao Huang wrote: >> On Mon, 09 Oct 2023 21:12:27 -0500, Huang, Kai >> wrote: >> >> > >> > > > > > >> > > > > Later the hosting process could migrated/reassigned to another >> > > cgroup? >> > > > > What to do when the new cgroup is OOM? >> > > > > >> > > > >> > > > You addressed in the documentation, no? >> > > > >> > > > +Migration >> > > > +--------- >> > > > + >> > > > +Once an EPC page is charged to a cgroup (during allocation), it >> > > > +remains charged to the original cgroup until the page is released >> > > > +or reclaimed. Migrating a process to a different cgroup doesn't >> > > > +move the EPC charges that it incurred while in the previous >> cgroup >> > > > +to its new cgroup. >> > > >> > > Should we kill the enclave though because some VA pages may be in >> the >> > > new >> > > group? >> > > >> > >> > I guess acceptable? >> > >> > And any difference if you keep VA/SECS to unreclaimabe list? >> >> Tracking VA/SECS allows all cgroups, in which an enclave has allocation, >> to identify the enclave following the back pointer and kill it as >> needed. >> >> > If you migrate one >> > enclave to another cgroup, the old EPC pages stay in the old cgroup >> > while the >> > new one is charged to the new group IIUC. >> > >> > I am not cgroup expert, but by searching some old thread it appears >> this >> > isn't a >> > supported model: >> > >> > https://lore.kernel.org/lkml/YEyR9181Qgzt+Ps9@mtj.duckdns.org/ >> > >> >> IIUC it's a different problem here. If we don't track the allocated VAs >> in >> the new group, then the enclave that spans the two groups can't be >> killed >> by the new group. If so, some enclave could just hide in some small >> group >> and never gets killed but keeps allocating in a different group? >> > > I mean from the link above IIUC migrating enclave among different > cgroups simply > isn't a supported model, thus any bad behaviour isn't a big concern in > terms of > decision making. If we leave some pages in a cgroup unkillable, we are in the same situation of not able to enforce a cgroup limit as that we are are in if we don't kill VMs for lower limits. I think not supporting migration of pages between cgroups should not leave a gap for enforcement just like we don't want to have an enforcement gap if we let VMs to hold pages once it is launched. Haitao