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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D97D4C4338F for ; Mon, 16 Aug 2021 12:09:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4749E63244 for ; Mon, 16 Aug 2021 12:09:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4749E63244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C25A18D0001; Mon, 16 Aug 2021 08:08:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD6FD6B0072; Mon, 16 Aug 2021 08:08:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC46D8D0001; Mon, 16 Aug 2021 08:08:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 8ECD56B0071 for ; Mon, 16 Aug 2021 08:08:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 241511C320 for ; Mon, 16 Aug 2021 12:08:59 +0000 (UTC) X-FDA: 78480822798.10.37A039D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 64B54600B66D for ; Mon, 16 Aug 2021 12:08:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EO3WapSK214OZ9yh3pHLXXJh6QKbdMb2/Uqc1lKIh/c=; b=QjKfc84jzubJb9dS0JcOUg50yA KdaOH+hqZoNr9IsKlJS1TM1iTVVrydrA5I0mh3aTtakVyxT8SH7iGjZsNdbwsoCX8tg5ZMj9Y3CbZ dFvwbE4VZ/e0N9wxoKIfsNZcHe9FA9f5szf2TRGcl8EeLHP0WjlOghTcbWV8JN50Osk3GS3PErZbI gTxntBeIL+afLxzLO8oyXZvRGoj76wC/2Gs0J/Vb23V4BKzU3TC/qtfhXXKQOq72gWjpN1D1xEz/g wq3iIVZR4DTacAFD8/PqyXL95zgKDWT0zRZAHO9G+/QERVj/B8uknat5q1nFCcWuCyc6KPdKMrCKE EGTwfjFg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFbPK-001K7e-82; Mon, 16 Aug 2021 12:08:13 +0000 Date: Mon, 16 Aug 2021 13:07:58 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Khalid Aziz , "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" , Steven Sistare , Anthony Yznaga , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Gonglei (Arei)" Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC Message-ID: References: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> <43471cbb-67c6-f189-ef12-0f8302e81b06@oracle.com> <55720e1b39cff0a0f882d8610e7906dc80ea0a01.camel@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 64B54600B66D Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QjKfc84j; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam01 X-Stat-Signature: z9r6jqhetzeyyfdsyn75qun1g4dfgw1c X-HE-Tag: 1629115738-932158 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Aug 16, 2021 at 10:02:22AM +0200, David Hildenbrand wrote: > > Mappings within this address range behave as if they were shared > > between threads, so a write to a MAP_PRIVATE mapping will create a > > page which is shared between all the sharers. The first process that > > declares an address range mshare'd can continue to map objects in the > > shared area. All other processes that want mshare'd access to this > > memory area can do so by calling mshare(). After this call, the > > address range given by mshare becomes a shared range in its address > > space. Anonymous mappings will be shared and not COWed. > > Did I understand correctly that you want to share actual page tables between > processes and consequently different MMs? That sounds like a very bad idea. That is the entire point. Consider a machine with 10,000 instances of an application running (process model, not thread model). If each application wants to map 1TB of RAM using 2MB pages, that's 4MB of page tables per process or 40GB of RAM for the whole machine. There's a reason hugetlbfs was enhanced to allow this page table sharing. I'm not a fan of the implementation as it gets some locks upside down, so this is an attempt to generalise the concept beyond hugetlbfs. Think of it like partial threading. You get to share some parts, but not all, of your address space with your fellow processes. Obviously you don't want to expose this to random other processes, only to other instances of yourself being run as the same user.