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 55689C433F5 for ; Fri, 21 Jan 2022 07:35:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD06A6B007D; Fri, 21 Jan 2022 02:35:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A58B06B007E; Fri, 21 Jan 2022 02:35:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 920646B0085; Fri, 21 Jan 2022 02:35:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 7F8EC6B007D for ; Fri, 21 Jan 2022 02:35:31 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3586190F5A for ; Fri, 21 Jan 2022 07:35:31 +0000 (UTC) X-FDA: 79053484062.21.8DDF9E3 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf16.hostedemail.com (Postfix) with ESMTP id A6326180005 for ; Fri, 21 Jan 2022 07:35:30 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id c24so37042077edy.4 for ; Thu, 20 Jan 2022 23:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RP302OUQarqJcKlS/8U/UoHcxHB/87qXxuKZS5RzpFU=; b=RYeMyMypdwPcT6x0u3IHpo9uVGKAHlUmZMpJlcV90hHzqRU6odtfB9sRHxDRNHvXFP s/zENm+ToIMnjD/m2uZdeKP1NkhKuJqb5LORO1wgUa1EgrM89wCzq3fYLTSxhjCzHmqD oyN0jnACc8N03BmUxGn2a4kRUYInNwNrSSs7uvdjk3SUXvvK0wBUrhQlrJUk9IMuhqOZ 5iRvlbzTIoYgucR+FXlvPy4jp3ChdS44Dzp0TCOSikdg+jv+93aFhGOqRLZyZcxmnQDx ymoIwadBur0wpHSYPBbyU6PN5AIpDf4/akzZKP375NppFOI8LUvAb8u8eeJeACz2ZrDg A2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RP302OUQarqJcKlS/8U/UoHcxHB/87qXxuKZS5RzpFU=; b=M6z6en2eOW16cs4inbtf8bf7lj/CarNAtTkjHhLmRlSVyYYgiHZ2rEquBS2dSljZpt +ePrlnG4YkP9CA1uXyxws6DmWXjfhKgQ6GD19uf+CtiW9j+SG0qH82rBeZguamODOKJA ivEmOtss6SVtY953ls9xoh62CIHfAWTGj8s55pfcKlVUEc1JrWtABoAUwE0T5AbPSIBS JGtdvj92lSTQXQG/N9x0yIk8Ms4Xt/Dw2CIyvcxxD4GrzW7l84X8oiW+sCGTe4Tmv7lc 0v4vcTGU7Zy7/suHbvgrUrCAKTgsw1dNQSuhVB+DciNSwUwl5royRpPSE7WOCYQk3lqr 0WfA== X-Gm-Message-State: AOAM532muna6bA93RhycKIteoDaa87pMLlRrWFsw0Hr2Ks/yQyx3vEbz raNu3mpkB5RHsWQk3ohTVlCDnaUdlXJ4T/3tB0o= X-Google-Smtp-Source: ABdhPJx6nhfumz35Z0K9DwZnIQuhwfPKh7CTID41/qxla6epld7pxIMQ+ihoBQ6hS3ICWXTGhGR292rZKUqJsbVJKcs= X-Received: by 2002:a17:907:c1c:: with SMTP id ga28mr849719ejc.502.1642750528776; Thu, 20 Jan 2022 23:35:28 -0800 (PST) MIME-Version: 1.0 References: <20220121010806.5607-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 21 Jan 2022 20:35:17 +1300 Message-ID: Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes To: Matthew Wilcox Cc: khalid.aziz@oracle.com, Andrew Morton , Arnd Bergmann , Dave Hansen , David Hildenbrand , LKML , Linux-MM , longpeng2@huawei.com, Mike Rapoport , Suren Baghdasaryan Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A6326180005 X-Stat-Signature: ewmu5eq1y9o9za9wqjkjku6uqjfr6qmc Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RYeMyMyp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-HE-Tag: 1642750530-223822 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 Fri, Jan 21, 2022 at 3:13 PM Matthew Wilcox wrote: > > On Fri, Jan 21, 2022 at 09:08:06AM +0800, Barry Song wrote: > > > A file under /sys/fs/mshare can be opened and read from. A read from > > > this file returns two long values - (1) starting address, and (2) > > > size of the mshare'd region. > > > > > > -- > > > int mshare_unlink(char *name) > > > > > > A shared address range created by mshare() can be destroyed using > > > mshare_unlink() which removes the shared named object. Once all > > > processes have unmapped the shared object, the shared address range > > > references are de-allocated and destroyed. > > > > > mshare_unlink() returns 0 on success or -1 on error. > > > > I am still struggling with the user scenarios of these new APIs. This patch > > supposes multiple processes will have same virtual address for the shared > > area? How can this be guaranteed while different processes can map different > > stack, heap, libraries, files? > > The two processes choose to share a chunk of their address space. > They can map anything they like in that shared area, and then also > anything they like in the areas that aren't shared. They can choose > for that shared area to have the same address in both processes > or different locations in each process. > > If two processes want to put a shared library in that shared address > space, that should work. They probably would need to agree to use > the same virtual address for the shared page tables for that to work. we are depending on an elf loader and ld to map the library dynamically , so hardly can we find a chance in users' code to call mshare() to map libraries in application level? so we are supposed to modify some very low level code to use this feature? > > Processes should probably not put their stacks in the shared region. > I mean, it could work, I suppose ... threads manage it in a single > address space. But I don't see why you'd want to do that. For > heaps, if you want the other process to be able to access the memory, > I suppose you could put it in the shared region, but heaps aren't > going to be put in the shared region by default. > > Think of this like hugetlbfs, only instead of sharing hugetlbfs > memory, you can share _anything_ that's mmapable. yep, we can call mshare() on any kind of memory. for example, if multiple processes use SYSV shmem, posix shmem or mmap the same file. but it seems it is more sensible to let kernel do it automatically rather than depending on calling mshare() from users? It is difficult for users to decide which areas should be applied mshare(). users might want to call mshare() for all shared areas to save memory coming from duplicated PTEs? unlike SYSV shmem and POSIX shmem which are a feature for inter-processes communications, mshare() looks not like a feature for applications, but like a feature for the whole system level? why would applications have to call something which doesn't directly help them? without mshare(), those applications will still work without any problem, right? is there anything in mshare() which is a must-have for applications? or mshare() is only a suggestion from applications like madvise()? > > > BTW, it seems you have different intention with the below? > > Shared page tables during fork[1] > > [1] https://lwn.net/Articles/861547/ > > Yes, that's completely different. Thanks for clarification. Best Regards. Barry