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 31452C2BA4C for ; Wed, 26 Jan 2022 04:05:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 436F36B0072; Tue, 25 Jan 2022 23:05:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E6216B0075; Tue, 25 Jan 2022 23:05:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AE136B0078; Tue, 25 Jan 2022 23:05:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 174AB6B0072 for ; Tue, 25 Jan 2022 23:05:16 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AA821180D32E0 for ; Wed, 26 Jan 2022 04:05:15 +0000 (UTC) X-FDA: 79071098190.09.9B4C78E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 7834B180009 for ; Wed, 26 Jan 2022 04:05:14 +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=EPZFnvZSWtUChiByJXbpNdnEgj2wHr/YrtyphezMlas=; b=BBI1rbHtRZSKR2sbOcH13dmoNT y5yXJMal1+Uj54eCJG+FCI1ETERDdclBEcueKTbe4P0phjm0qh/sTnZISl/TDDVpMyVQyAgFtbM15 EmGXjM26rumanCA1V9JoY054wqvTc/c4RPHsoWDz2dPRkx/WJKbI1rVPIjH0JFZ3srGcF5K6P1aNG Rhwmlsd4UqcLPDpHMJ5RMOhgHAhXCf+VVUZhb/4WMu82BWMdGUo/stCaJ6EPA7ElcLjLw632r5ktS xrtIUvkEsPgRoJXx/QJA9LNoCTrf6XJVOSRPDC46UsgQQ9I97Jcr9e3CvUzqWEFNbyii7wiV9dbPf 6vaIM4xw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCZY8-003hFg-Gl; Wed, 26 Jan 2022 04:04:48 +0000 Date: Wed, 26 Jan 2022 04:04:48 +0000 From: Matthew Wilcox To: "Kirill A. Shutemov" Cc: Khalid Aziz , akpm@linux-foundation.org, longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, rppt@kernel.org, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes Message-ID: References: <20220125114212.ks2qtncaahi6foan@box.shutemov.name> <20220125135917.ezi6itozrchsdcxg@box.shutemov.name> <20220125185705.wf7p2l77vggipfry@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7834B180009 X-Rspam-User: nil Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BBI1rbHt; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: oph89cj9rarzs385rek5g8mnfi4q6z3s X-Rspamd-Server: rspam08 X-HE-Tag: 1643169914-671704 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 Tue, Jan 25, 2022 at 06:59:50PM +0000, Matthew Wilcox wrote: > On Tue, Jan 25, 2022 at 09:57:05PM +0300, Kirill A. Shutemov wrote: > > On Tue, Jan 25, 2022 at 02:09:47PM +0000, Matthew Wilcox wrote: > > > > I think zero-API approach (plus madvise() hints to tweak it) is worth > > > > considering. > > > > > > I think the zero-API approach actually misses out on a lot of > > > possibilities that the mshare() approach offers. For example, mshare() > > > allows you to mmap() many small files in the shared region -- you > > > can't do that with zeroAPI. > > > > Do you consider a use-case for many small files to be common? I would > > think that the main consumer of the feature to be mmap of huge files. > > And in this case zero enabling burden on userspace side sounds like a > > sweet deal. > > mmap() of huge files is certainly the Oracle use-case. With occasional > funny business like mprotect() of a single page in the middle of a 1GB > hugepage. Bill and I were talking about this earlier and realised that this is the key point. There's a requirement that when one process mprotects a page that it gets protected in all processes. You can't do that without *some* API because that's different behaviour than any existing API would produce. So how about something like this ... int mcreate(const char *name, int flags, mode_t mode); creates a new mm_struct with a refcount of 2. returns an fd (one of the two refcounts) and creates a name for it (inside msharefs, holds the other refcount). You can then mmap() that fd to attach it to a chunk of your address space. Once attached, you can start to populate it by calling mmap() and specifying an address inside the attached mm as the first argument to mmap(). Maybe mcreate() is just a library call, and it's really a thin wrapper around open() that happens to know where msharefs is mounted.