From: William Kucharski <kucharsk@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Khalid Aziz <khalid.aziz@oracle.com>,
akpm@linux-foundation.org, willy@infradead.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
Date: Tue, 25 Jan 2022 05:09:03 -0700 [thread overview]
Message-ID: <E44A9AB1-DBF0-4B8E-B049-293DD4DE6093@gmail.com> (raw)
In-Reply-To: <20220125114212.ks2qtncaahi6foan@box.shutemov.name>
I would think this should be the case; certainly it seems to be a more effective approach than having to manually enable sharing via the API in every case or via changes to ld.so.
If anything it might be useful to have an API for shutting it off, though there are already multiple areas where the system shares resources in ways that cannot be shut off by user action.
> On Jan 25, 2022, at 04:41, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>
> On Tue, Jan 18, 2022 at 02:19:12PM -0700, Khalid Aziz wrote:
>> Example Code
>> ============
>>
>> Snippet of the code that a donor process would run looks like below:
>>
>> -----------------
>> addr = mmap((void *)TB(2), GB(512), PROT_READ | PROT_WRITE,
>> MAP_SHARED | MAP_ANONYMOUS, 0, 0);
>> if (addr == MAP_FAILED)
>> perror("ERROR: mmap failed");
>>
>> err = syscall(MSHARE_SYSCALL, "testregion", (void *)TB(2),
>> GB(512), O_CREAT|O_RDWR|O_EXCL, 600);
>> if (err < 0) {
>> perror("mshare() syscall failed");
>> exit(1);
>> }
>>
>> strncpy(addr, "Some random shared text",
>> sizeof("Some random shared text"));
>> -----------------
>>
>> Snippet of code that a consumer process would execute looks like:
>>
>> -----------------
>> fd = open("testregion", O_RDONLY);
>> if (fd < 0) {
>> perror("open failed");
>> exit(1);
>> }
>>
>> if ((count = read(fd, &mshare_info, sizeof(mshare_info)) > 0))
>> printf("INFO: %ld bytes shared at addr %lx \n",
>> mshare_info[1], mshare_info[0]);
>> else
>> perror("read failed");
>>
>> close(fd);
>>
>> addr = (char *)mshare_info[0];
>> err = syscall(MSHARE_SYSCALL, "testregion", (void *)mshare_info[0],
>> mshare_info[1], O_RDWR, 600);
>> if (err < 0) {
>> perror("mshare() syscall failed");
>> exit(1);
>> }
>>
>> printf("Guest mmap at %px:\n", addr);
>> printf("%s\n", addr);
>> printf("\nDone\n");
>>
>> err = syscall(MSHARE_UNLINK_SYSCALL, "testregion");
>> if (err < 0) {
>> perror("mshare_unlink() failed");
>> exit(1);
>> }
>> -----------------
>
> I wounder if we can get away with zero-API here: we can transparently
> create/use shared page tables for any inode on mmap(MAP_SHARED) as long as
> size and alignment is sutiable. Page tables will be linked to the inode
> and will be freed when the last of such mapping will go away. I don't see
> a need in new syscalls of flags to existing one.
>
> --
> Kirill A. Shutemov
>
next prev parent reply other threads:[~2022-01-25 12:09 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 21:19 Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 1/6] mm: Add new system calls mshare, mshare_unlink Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 2/6] mm: Add msharefs filesystem Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 3/6] mm: Add read for msharefs Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 4/6] mm: implement mshare_unlink syscall Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 5/6] mm: Add locking to msharefs syscalls Khalid Aziz
2022-01-18 21:19 ` [RFC PATCH 6/6] mm: Add basic page table sharing using mshare Khalid Aziz
2022-01-18 21:41 ` [RFC PATCH 0/6] Add support for shared PTEs across processes Dave Hansen
2022-01-18 21:46 ` Matthew Wilcox
2022-01-18 22:47 ` Khalid Aziz
2022-01-18 22:06 ` Dave Hansen
2022-01-18 22:52 ` Khalid Aziz
2022-01-19 11:38 ` Mark Hemment
2022-01-19 17:02 ` Khalid Aziz
2022-01-20 12:49 ` Mark Hemment
2022-01-20 19:15 ` Khalid Aziz
2022-01-24 15:15 ` Mark Hemment
2022-01-24 15:27 ` Matthew Wilcox
2022-01-24 22:20 ` Khalid Aziz
2022-01-21 1:08 ` Barry Song
2022-01-21 2:13 ` Matthew Wilcox
2022-01-21 7:35 ` Barry Song
2022-01-21 14:47 ` Matthew Wilcox
2022-01-21 16:41 ` Khalid Aziz
2022-01-22 1:39 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2022-01-22 1:41 ` Matthew Wilcox
2022-01-22 10:18 ` Thomas Schoebel-Theuer
2022-01-22 16:09 ` Matthew Wilcox
2022-01-22 11:31 ` Mike Rapoport
2022-01-22 18:29 ` Andy Lutomirski
2022-01-24 18:48 ` Khalid Aziz
2022-01-24 19:45 ` Andy Lutomirski
2022-01-24 22:30 ` Khalid Aziz
2022-01-24 23:16 ` Andy Lutomirski
2022-01-24 23:44 ` Khalid Aziz
2022-01-25 11:42 ` Kirill A. Shutemov
2022-01-25 12:09 ` William Kucharski [this message]
2022-01-25 13:18 ` David Hildenbrand
2022-01-25 14:01 ` Kirill A. Shutemov
2022-01-25 13:23 ` Matthew Wilcox
2022-01-25 13:59 ` Kirill A. Shutemov
2022-01-25 14:09 ` Matthew Wilcox
2022-01-25 18:57 ` Kirill A. Shutemov
2022-01-25 18:59 ` Matthew Wilcox
2022-01-26 4:04 ` Matthew Wilcox
2022-01-26 10:16 ` David Hildenbrand
2022-01-26 13:38 ` Matthew Wilcox
2022-01-26 13:55 ` David Hildenbrand
2022-01-26 14:12 ` Matthew Wilcox
2022-01-26 14:30 ` David Hildenbrand
2022-01-26 14:12 ` Mike Rapoport
2022-01-26 13:42 ` Kirill A. Shutemov
2022-01-26 14:18 ` Mike Rapoport
2022-01-26 17:33 ` Khalid Aziz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E44A9AB1-DBF0-4B8E-B049-293DD4DE6093@gmail.com \
--to=kucharsk@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=khalid.aziz@oracle.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longpeng2@huawei.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox