From: Thomas Schoebel-Theuer <tst@schoebel-theuer.de>
To: Matthew Wilcox <willy@infradead.org>,
"Longpeng (Mike,
Cloud Infrastructure Service Product Dept.)"
<longpeng2@huawei.com>
Cc: Khalid Aziz <khalid.aziz@oracle.com>,
Barry Song <21cnbao@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes
Date: Sat, 22 Jan 2022 11:18:14 +0100 [thread overview]
Message-ID: <cb55951f-3c30-61e3-23a3-7a99064918b7@schoebel-theuer.de> (raw)
In-Reply-To: <Yetgy/eT+rZBgSq7@casper.infradead.org>
On 1/22/22 2:41 AM, Matthew Wilcox wrote:
> On Sat, Jan 22, 2022 at 01:39:46AM +0000, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) wrote:
>>>> Our use case is that we have some very large files stored on persistent
>>>> memory which we want to mmap in thousands of processes. So the first
>> The memory overhead of PTEs would be significantly saved if we use
>> hugetlbfs in this case, but why not?
> Because we want the files to be persistent across reboots.
100% agree. There is another use case: geo-redundancy.
My view is publicly documented at
https://github.com/schoebel/mars/tree/master/docu and click at
architecture-guide-geo-redundancy.pdf
In some scenarios, migration or (temporary) co-existence of block
devices from/between hardware architecture A to/between hardware
architecture B might become a future requirement for me.
The currrent implementation does not yet use hugetlbfs and/or its
proposed / low-overhead / more fine-grained and/or less
hardware-architecture specific (future) alternatives.
For me, all of these are future options. In particular, when (1)
abstractable for reduction of architectural dependencies, and hopefully
(2) usable from both kernelspace and userspace.
It would be great if msharefs is not only low-footprint, but also would
be usable from kernelspace.
Reduction (or getting rid) of preallocation strategies would be also a
valuable feature for me.
Of course, I cannot decide what I will prefer in future for any future
requirements. But some kind of mutual awareness and future collaboration
would be great.
next prev parent reply other threads:[~2022-01-22 10:18 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 [this message]
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
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=cb55951f-3c30-61e3-23a3-7a99064918b7@schoebel-theuer.de \
--to=tst@schoebel-theuer.de \
--cc=21cnbao@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=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