On Sat, Jan 22, 2022 at 11:18:14AM +0100, Thomas Schoebel-Theuer wrote: > 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 That's a 160+ page PDF. No offence, Thomas, I'm not reading that to try to understand how you want to use page table sharing. > 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. I'm not sure how sharing block devices between systems matches up with sharing page tables between processes. > It would be great if msharefs is not only low-footprint, but also would be > usable from kernelspace. I don't understand what you want here either. Kernel threads already share their page tables.
