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 DE039C54EE9 for ; Thu, 22 Sep 2022 21:04:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230283AbiIVVED (ORCPT ); Thu, 22 Sep 2022 17:04:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230293AbiIVVD7 (ORCPT ); Thu, 22 Sep 2022 17:03:59 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3A1210CA7C; Thu, 22 Sep 2022 14:03: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=1663880637; x=1695416637; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5J/gUw0ozggdiEjT67Hv+Q1CO877q7WnX+QC9z+OreE=; b=cGQ3FhvmCEU1br1E/02+iXJWgWqgjpHiM7usoLkViCJf2toyn5wGQ0lM cB9bf8ZoQ3RbJYV1V4uTEpxLaL3kpdnGs75jXqD7J4sLS0Fb3RbYcluu4 eUShQ4xROSserw5YPRhlCH04kULGlB1z81+3p9dzsFomQCYGs8eCn9Py+ bS/ehEOKPfGP+h5MX8wXsAC+kccGePgmXeU9Hs+ySTR4Zys3J86fR8Cuc 9qFmqDtGEwZU/3ylxF/bm6QjM8ZroTdK1n6C4GkUByo+dl6eZIZIhOuvE Yr15QatCUwEz7NBDpxOdEcTlqxRpIgtnRxUpBv0Ef39lulSw0wLBrQlT4 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="301870386" X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="301870386" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 14:03:52 -0700 X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="948770813" Received: from sponnura-mobl1.amr.corp.intel.com (HELO [10.209.58.200]) ([10.209.58.200]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 14:03:51 -0700 Message-ID: <7ff6d114-a6cc-e3c5-5edb-8ac0e527d8a9@intel.com> Date: Thu, 22 Sep 2022 14:03:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC PATCH 00/20] Add Cgroup support for SGX EPC memory Content-Language: en-US To: Tejun Heo , Kristen Carlson Accardi Cc: linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org, cgroups@vger.kernel.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song References: <20220922171057.1236139-1-kristen@linux.intel.com> <4b8605533e5deade739249bfb341ab9c06d56a1e.camel@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On 9/22/22 12:08, Tejun Heo wrote: > Can you please give more concrete examples? I'd love to hear how the SGX EPC > memory is typically used in what amounts and what's the performance > implications when they get reclaimed and so on. ie. Please describe a > realistic usage scenario of contention with sufficient details on how the > system is set up, what the applications are using the SGX EPC memory for and > how much, how the contention on memory affects the users and so on. One wrinkle is that the apps that use SGX EPC memory are *normal* apps. There are frameworks that some folks are very excited about that allow you to run mostly unmodified app stacks inside SGX. For example: https://github.com/gramineproject/graphene In fact, Gramine users are the troublesome ones for overcommit. Most explicitly-written SGX applications are quite austere in their SGX memory use; they're probably never going to see overcommit. These Gramine-wrapped apps are (relative) pigs. They've been the ones finding bugs in the existing SGX overcommit code. So, where does all the SGX memory go? It's the usual suspects: memcached and redis. ;)