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 E4012C433FE for ; Tue, 11 Jan 2022 15:43:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245754AbiAKPnw (ORCPT ); Tue, 11 Jan 2022 10:43:52 -0500 Received: from mga14.intel.com ([192.55.52.115]:45578 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240010AbiAKPnu (ORCPT ); Tue, 11 Jan 2022 10:43:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641915830; x=1673451830; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=mbYhbfEPWbz/jPT9cqRRXX3BhHy6E2iOrDNTHn/NRDk=; b=CtgQM56VgdNUncEHPiIB0+fBBdPLrwjemY3QtTSc5YOzgyq5XMCUfPXr /Je6iEBUu7Vfdon8mMRm0OyUBSrHiktgwqKqVXiXyZTbyzEW6105vZVPw Xupfioji8lc7If1YwmdwNWzmKN86RyhN1vLzPKWF16gyXe18tc3SGIT3X 20oUFf1N6HTS93uj7cETdJVP9BCmo/YwQ0UqWqx0gaBqBb9UGbRDjZAe7 //04mOfoYhh6NmCxK+oTvLtuIlh/pKfVDjyRwR9YE1vhBkgz16NoCTWyZ XmqYeAI3ZKjaTyrZpW0rw1YqIYqC8y8Xg3/u9n2MaI6QEM76k+pgRbOmI g==; X-IronPort-AV: E=McAfee;i="6200,9189,10223"; a="243713762" X-IronPort-AV: E=Sophos;i="5.88,279,1635231600"; d="scan'208";a="243713762" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2022 07:43:50 -0800 X-IronPort-AV: E=Sophos;i="5.88,279,1635231600"; d="scan'208";a="613254996" Received: from padhika1-mobl.amr.corp.intel.com (HELO [10.209.13.65]) ([10.209.13.65]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2022 07:43:36 -0800 Message-ID: Date: Tue, 11 Jan 2022 07:43:35 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH v2 1/2] x86/sgx: Add accounting for tracking overcommit Content-Language: en-US To: Haitao Huang , linux-sgx@vger.kernel.org, Jarkko Sakkinen , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Kristen Carlson Accardi Cc: linux-kernel@vger.kernel.org References: <20220107181618.6597-1-kristen@linux.intel.com> <20220107181618.6597-2-kristen@linux.intel.com> <171631a9-aaec-f590-3377-29c13fc6041e@intel.com> <3b169fde457f28e086c49c8a3b8d81ac539cfb59.camel@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/11/22 06:20, Haitao Huang wrote: > If the system has a ton of RAM but limited EPC, I think it makes sense > to allow more EPC swapping, can we do min(0.5*RAM, 2*EPC)? > I suppose if the system is used for heavy enclave load, user would be > willing to at least use half of RAM. If I have 100GB of RAM and 100MB of EPC, can I really *meaningfully* run 50GB of enclaves? In that case, if everything was swapped out evenly, I would only have a 499/500 chance that a given page reference would fault. This isn't about a "heavy enclave load". If there is *that* much swapped-out enclave memory, will an enclave even make meaningful forward progress?