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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF73DC433EF for ; Mon, 11 Apr 2022 18:51:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 570026B0072; Mon, 11 Apr 2022 14:51:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 520156B0073; Mon, 11 Apr 2022 14:51:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E6B66B0074; Mon, 11 Apr 2022 14:51:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 2E4426B0072 for ; Mon, 11 Apr 2022 14:51:46 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0AF6C24782 for ; Mon, 11 Apr 2022 18:51:46 +0000 (UTC) X-FDA: 79345492212.13.94E8F95 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf03.hostedemail.com (Postfix) with ESMTP id 1E64720002 for ; Mon, 11 Apr 2022 18:51:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649703105; x=1681239105; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=3NS2IckigsYPCW6uvTWzWoNogEPw6kTBCLQLlVDSA/w=; b=T7V2HrRZ9M6ciCu1E6e2VCOyLQweoYMoyv72lWShUIbUjMmhklU1qYjW dGKtH5V5Ji5Pzo/4ZPosUqPnXNhRHN4dErEWYCRQgwItNQfEZn4h01/g+ G3phRtRqdsEUgPqo6OxmP3vDSkK87qYQkWepXaYOCYPXK9pFcZIp64rn0 9bTZ6MzhM5STNXbw+JYQjM12RQSYCrvRWiKZnXfyta6gi06WDCA752xce qlzihIFQIAWwYeXsy6Zs7sYlgOuRv5FBKBqgmbdyZhL7tS30gqqqXelSk MHDDIFRSgbsRAXQeBepokiplJW2cJHxtIPkBy/u86KrozRAACepJ5IHpH g==; X-IronPort-AV: E=McAfee;i="6400,9594,10314"; a="244073127" X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="244073127" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 11:51:43 -0700 X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="572339167" Received: from minhjohn-mobl.amr.corp.intel.com (HELO [10.212.44.201]) ([10.212.44.201]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 11:51:41 -0700 Message-ID: Date: Mon, 11 Apr 2022 11:51:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Matthew Wilcox , Khalid Aziz Cc: akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, arnd@arndb.de, 21cnbao@gmail.com, corbet@lwn.net, dave.hansen@linux.intel.com, david@redhat.com, ebiederm@xmission.com, hagen@jauu.net, jack@suse.cz, keescook@chromium.org, kirill@shutemov.name, kucharsk@gmail.com, linkinjeon@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, longpeng2@huawei.com, luto@kernel.org, markhemm@googlemail.com, pcc@google.com, rppt@kernel.org, sieberf@amazon.com, sjpark@amazon.de, surenb@google.com, tst@schoebel-theuer.de, yzaikin@google.com References: From: Dave Hansen Subject: Re: [PATCH v1 00/14] Add support for shared PTEs across processes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=T7V2HrRZ; spf=none (imf03.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Stat-Signature: efqszc1kjm7sepgs4r3ckxz6whz7tftm X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1E64720002 X-HE-Tag: 1649703104-988939 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/11/22 10:37, Matthew Wilcox wrote: > Another argument that MM developers find compelling is that we can reduce > some of the complexity in hugetlbfs where it has the ability to share > page tables between processes. When could this complexity reduction actually happen in practice? Can this mshare thingy be somehow dropped in underneath the existing hugetlbfs implementation? Or would userspace need to change?