Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp28587pxb; Tue, 12 Apr 2022 15:53:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8dWMemBzpAqqNtFOkKkDEIHWe3ftcrc1KiA9ZOPZ61NyzAq3xQvv3JVsJk6aCEA2puJeg X-Received: by 2002:a17:902:d344:b0:158:4bd9:34a7 with SMTP id l4-20020a170902d34400b001584bd934a7mr16635640plk.22.1649804025825; Tue, 12 Apr 2022 15:53:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649804025; cv=none; d=google.com; s=arc-20160816; b=oqCNBhSB0ZCmCv5bc1dB2FmQwpAazWB4I/fe0HdykltcQpNkUDFpRh+5R+ZiPsIKV/ aEMeDUI90K3qeSWIHlCoqCLXXmo4OIWr17OBklWxkayCQoSg3nVoZa5bgbumeMsHp9Mn ZpY9VwG0K8zzOYGFbk4oJrMM5WEtCKNt8opY58pZm60RRImVLWMZ/lTHIc174XGIMolF Rot1UY0xjF3YgyP7bYClrtJY9WF1mpmUT3eOke2mVtXrnKPcfJtqxCSz7jWiuh54g0x3 LveaHKWqh5n24y7Ccbq+YiDxfPqcPaXld3/hFe5TPVMGtv5dRu8DIlbgVz7Rzph1/D0g YPgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=l9cBcpo8Qod94TraAQkpm/pmOkonuGfcxpmazHENaPE=; b=HS5wp5s+RmbjzH76j5AkBaybVTcQAeTIpnQUugcIeq1OVvwDYs+03glLNEDhd0YW0i X8P81S8rQMBNygF3ha/ySW/VBEfsaeEkW3/zv5+ukF9cYxfmF4OjzGDjk9A+utsNL1Cc eIvJVAv/FmA3pNGVcJ3UvapnAf92188HpvLQDimyWbtw2nj3gLr33NqWwsWLU6eSRzc7 ipikv150IXHvqq12H9ggB7nN8lxPL6J0PcCRB72FxviCQ0zaYvG0/nLM1CTGODuj3ziQ wBImS2ojeh/CFip9M2zH6x7QOXnBNGfxY54SqQU9cSSfsihARCvUhrFIS7H2S1Q3Bb2K F4CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YFXU9kPU; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 6-20020a630a06000000b0039da5929a26si2317466pgk.24.2022.04.12.15.53.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 15:53:45 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YFXU9kPU; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 714FD1CA13A; Tue, 12 Apr 2022 14:35:45 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349274AbiDKSyA (ORCPT + 99 others); Mon, 11 Apr 2022 14:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349257AbiDKSx6 (ORCPT ); Mon, 11 Apr 2022 14:53:58 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FD9612616; Mon, 11 Apr 2022 11:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649703104; x=1681239104; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=3NS2IckigsYPCW6uvTWzWoNogEPw6kTBCLQLlVDSA/w=; b=YFXU9kPUXNfX1I14Q3ebQ8+2Q+SxHCltlnTKIRqQFUQ2pjTfpCtqZQa3 JslkjZl9IqTHI0a0c+flDNstM4PH1BgLgbJPVXBTyUYjhLVPiE87I5idB YoW0bH++cgXQoBizvKRZHYRnBAXY3NYH0oI1w/zMXoXYQGSZiDU/PtEHs qYZGJJ1qsyt8iTd7OiCTnqGpv9f6ez+TPxpy6uonMrv8asnKHeEuz4n/E eVFvBIMPSEIRw1iGIjrpyooizzQ/4Y4mFIhfHYs5Sa/Z9J17trebwm/Am 70JsreTJQjb7X5okrZAKYMP+JZzdt8hA03z5Oq3G7zVZ49n1my/TOH9Da w==; X-IronPort-AV: E=McAfee;i="6400,9594,10314"; a="249471959" X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="249471959" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.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 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?