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 2B5E9C3526D for ; Wed, 26 Jan 2022 14:19:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 972326B0072; Wed, 26 Jan 2022 09:19:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9213F6B0074; Wed, 26 Jan 2022 09:19:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 810E26B0075; Wed, 26 Jan 2022 09:19:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 744666B0072 for ; Wed, 26 Jan 2022 09:19:10 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2CEC8884A0 for ; Wed, 26 Jan 2022 14:19:10 +0000 (UTC) X-FDA: 79072645260.28.8A52735 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id B1343100019 for ; Wed, 26 Jan 2022 14:19:09 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DDB4360907; Wed, 26 Jan 2022 14:19:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABF39C340E3; Wed, 26 Jan 2022 14:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643206748; bh=W1L1pIumJOUK3UmO17es5PZtmpZRwBpcqUO2tjQQsOM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ty+pUTnTqWyQhlRMY7OVCiRaETM2+ONRVT2XgXXmf/JdmDt5cZo42Y9NdrHGd8ddd OXJ0KLgFwgVfvy96AwMMO9dDJnBRGQJrGwnBGR62anfiXql15veBoIyM7cKV8/hwF8 1K0W8YppLfAUSNXDHi1zNEOn1CTjJK9xjYkHsbVonsk4kEcJeT5xLWzBfpFkV35ekJ GIU0oN1VkJ0TgJlSFzuYIBfVGS0P0eNGFNivhEsSDP+NvKTMSReRs+Dmj2itLuXv1U BcMZLbjXtRmwJE3LtffGZ0gpJ4DiUhO8m1NIfcYDZASAvLvFt3jwQHRYbQF4O9AmbA +sz+PlewMlQQQ== Date: Wed, 26 Jan 2022 16:18:57 +0200 From: Mike Rapoport To: "Kirill A. Shutemov" Cc: Matthew Wilcox , Khalid Aziz , akpm@linux-foundation.org, longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, 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> <20220126134247.fadtwbvyknh3ejpe@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126134247.fadtwbvyknh3ejpe@box.shutemov.name> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B1343100019 X-Stat-Signature: 1n7gspth5i6gioibyp8n8dqkx4xb771k Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ty+pUTnT; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspam-User: nil X-HE-Tag: 1643206749-868323 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 Wed, Jan 26, 2022 at 04:42:47PM +0300, Kirill A. Shutemov wrote: > On Wed, Jan 26, 2022 at 04:04:48AM +0000, Matthew Wilcox wrote: > > 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: > > > 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(). > > That is not what mmap() would normally do to an existing mapping. So it > requires special treatment. > > In general mmap() of a mm_struct scares me. I can't wrap my head around > implications. > > Like how does it work on fork()? > > How accounting works? What happens on OOM? > > What prevents creating loops, like mapping a mm_struct inside itself? > > What mremap()/munmap() do to such mapping? Will it affect mapping of > mm_struct or will it target mapping inside the mm_sturct? > > Maybe it just didn't clicked for me, I donno. My understanding was that the new mm_struct would be rather stripped and will be used more as an abstraction for the shared page table, maybe I'm totally wrong :) > > Maybe mcreate() is just a library call, and it's really a thin wrapper > > around open() that happens to know where msharefs is mounted. > > -- > Kirill A. Shutemov -- Sincerely yours, Mike.