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 C3F4EC433F5 for ; Sat, 22 Jan 2022 10:18:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7C276B00C2; Sat, 22 Jan 2022 05:18:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C2BE06B00C4; Sat, 22 Jan 2022 05:18:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF2A46B00C6; Sat, 22 Jan 2022 05:18:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay035.a.hostedemail.com [64.99.140.35]) by kanga.kvack.org (Postfix) with ESMTP id 9A6B96B00C2 for ; Sat, 22 Jan 2022 05:18:52 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 556C3233AF for ; Sat, 22 Jan 2022 10:18:52 +0000 (UTC) X-FDA: 79057524504.03.33EEE07 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.50]) by imf26.hostedemail.com (Postfix) with ESMTP id C8EB5140002 for ; Sat, 22 Jan 2022 10:18:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1642846695; s=strato-dkim-0002; d=schoebel-theuer.de; h=In-Reply-To:Date:Message-ID:References:Cc:To:Subject:From:Cc:Date: From:Subject:Sender; bh=8T8wzyEFV1gpfcMp5beb/aXparqxKKNBbKGp5R8qWvU=; b=WCkICED+u8UqCXNAn4Q6ec3VIfgAQioAw1TAu4XkEqOOpuIlCorxIE+ICU9SYmvjXt QFP5iTmHrT8aCDSd/MDbYLGBwbtQyYb8b2+E81yESNOiCtNCHrLxHZ8tqQRmz2EJ3Z8t VvTY4VoAES0QxOaNjkSyNY1lbtrkHz6+2EonIYa8SiCeYuHJl0IzC0sI1K7BJO1gzpff QR2Cyr2lwLTbQh97+2Cpx/hF0uh1sXirZQfBVTcnlUGJJzIaEUc2j1Hu0jYuSq/1v1GF BkUHu1f9Q50Ez8UYUlUxYLMkBp0/yT42fvV8upU/J9MYmSgKE9/20kTcQlpDT+MLSr5P 2tGA== X-RZG-AUTH: ":OH8QVVOrc/CP6za/qRmbF3BWedPGA1vjs2e0bDjfg8OiOrPJifeRMRhMYPeob5ctvymt3ppSxzy7" X-RZG-CLASS-ID: mo00 Received: from [192.168.2.102] by smtp.strato.de (RZmta 47.38.0 DYNA|AUTH) with ESMTPSA id 036fcey0MAIEB3H (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 22 Jan 2022 11:18:14 +0100 (CET) From: Thomas Schoebel-Theuer Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes To: Matthew Wilcox , "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" Cc: Khalid Aziz , Barry Song <21cnbao@gmail.com>, Andrew Morton , Arnd Bergmann , Dave Hansen , David Hildenbrand , LKML , Linux-MM , Mike Rapoport , Suren Baghdasaryan References: <20220121010806.5607-1-21cnbao@gmail.com> <0ec88ae7-9740-835d-1f07-60bd57081fcd@oracle.com> Message-ID: Date: Sat, 22 Jan 2022 11:18:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C8EB5140002 X-Stat-Signature: f5x3rkbn96h46q4z3birg7zszgsezkz8 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=schoebel-theuer.de header.s=strato-dkim-0002 header.b=WCkICED+; spf=none (imf26.hostedemail.com: domain of tst@schoebel-theuer.de has no SPF policy when checking 85.215.255.50) smtp.mailfrom=tst@schoebel-theuer.de; dmarc=none X-Rspam-User: nil X-HE-Tag: 1642846730-942698 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 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.