Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b95b651c-2e00-abdd-6d5a-5b3dea79dccb@oracle.com>
Date:   Thu, 27 Apr 2023 10:40:57 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.1
Subject: Re: [PATCH RFC v2 0/4] Add support for sharing page tables across
 processes (Previously mshare)
To:     Mike Kravetz <mike.kravetz@oracle.com>
Cc:     akpm@linux-foundation.org, willy@infradead.org,
        markhemm@googlemail.com, viro@zeniv.linux.org.uk, david@redhat.com,
        andreyknvl@gmail.com, dave.hansen@intel.com, luto@kernel.org,
        brauner@kernel.org, arnd@arndb.de, ebiederm@xmission.com,
        catalin.marinas@arm.com, linux-arch@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        mhiramat@kernel.org, rostedt@goodmis.org, vasily.averin@linux.dev,
        xhao@linux.alibaba.com, pcc@google.com, neilb@suse.de,
        maz@kernel.org
References: <cover.1682453344.git.khalid.aziz@oracle.com>
 <20230426212745.GA4755@monkey>
Content-Language: en-US
From:   Khalid Aziz <khalid.aziz@oracle.com>
In-Reply-To: <20230426212745.GA4755@monkey>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RURHZEFVSHI4eWdLN1NvWDdXL3JGMlR3Z0JTZnNsYTRhK3BqemsxT1NRZTV6?=
 =?utf-8?B?MnRueW1Ob29BeFJ2bURFa2lDdEtQQzVFMlBYNUxVT1FnT0hKcFFGK1QvTjB6?=
 =?utf-8?B?SjFNb0lTU28rRVF6NVdxa081d3lxbUdzYkltcnlqV2xEaFNObzU4UGoxZURB?=
 =?utf-8?B?Q3lzTFNSZm9hNzRMWjczZ1R0cnoyT0R0UXhXY1c3YkEwRVd3bG8xTGpobUN6?=
 =?utf-8?B?OS9JNGEyQjh3QXJPRUNRY1JwTEx0TlgyR1VzeVpubENZOXRZVUVpbnZVYXVj?=
 =?utf-8?B?cThHczVDTUl2Njh3K0JBSlQwU0txTzJKR2tKVmtJRFZVclhaSDN3ZU8rVlhG?=
 =?utf-8?B?T20yNE5vTzYwaldBcS9nQTRqbHRpR0NIeEwyWWtxU20ya3dRNmJSSVZ2bWhK?=
 =?utf-8?B?ZjNmWTZ6STdtZ2RhTUJFakpYN3FIVHYxNjYwdldWdWppVm1FK1BuYnpWWGl4?=
 =?utf-8?B?clA2Vi9OY3JReWdEcnBWVlJRQ1ZONDFpRE5Da3A2TE5GOVRxenNtWlBqUE42?=
 =?utf-8?B?SkhGRFUvc1JraGpPR1MrMWFUckRqck43NEVQZTlKbHZ4UnZCQXh3M2swMmhW?=
 =?utf-8?B?V3hxUWluQ01ycU5BOEhpZ09tL3pnTEV0cjAvNjRhMnQ4ZE5iRHppR3M0YzUr?=
 =?utf-8?B?L1NjR1M2dzQ2UU4vOFdWRHhxTy9taVhTeWhmWk8vYlB6bTJ1MkhTWlV2blVS?=
 =?utf-8?B?ZXN2Mm9jQ1cvUWd5VndzU2VOcUNEbURTTldjQWxnOVU4akl1N3FiUGIveUh5?=
 =?utf-8?B?Z1JKdmF3Q3krR3AzaGk4UUUwOWhGaDdJZm13eDhxaW5wYzZ0U2RGb3RudFY5?=
 =?utf-8?B?SVhJbEQ4a05GWGV6TUpGMHFyS05QSTQ3NWlPeEtySVdycHlaUEZsTWtIVW9R?=
 =?utf-8?B?ZjVxRis4ZzZVTlhnSVpzTHRjbXkrSyt3M1dkdVlkM1ZjamNUTG1SSFR2MnVI?=
 =?utf-8?B?YmthN1ZQbDdsV2xKMkt5M2RyL0F4ZW0zams3V0ljcGp2akdNRDNtU2NFeTZW?=
 =?utf-8?B?K29uL2hTT0VJU3dpYlorRk9RQXNxVDZqenA3OTE0OTJDQzFQc25Yd0l3NEVi?=
 =?utf-8?B?K3MrcEFHeDRyNnpNNmRIU3BNRzRvL04zQmlEVkZhWGtOQmtxbUU4NlZRVC9u?=
 =?utf-8?B?RktFTzF4ak1ZbHVubGlPbmQwWWdIc3VBZjNPenBJSFozTG5xR3g1TkphUjJL?=
 =?utf-8?B?cDNtK1FkTHpXL0JkdkJML0NkQ1l3N2tBcUh6MHczZXAyajNUL0ViVzZYU1VB?=
 =?utf-8?B?U2FjUGlwVDIwYVVOU1RzUnN0NUowY3R4V3VYNHRxcXNRUjlVd2cxcHlIRUkw?=
 =?utf-8?B?U2V5cEE1Snh1YVg1VzcrYThSWlB3M3BtdndkaW5GcW1BOENNY0w3Ukl5enZ4?=
 =?utf-8?B?NElKTVNpZDYvanZXSFlqUVYvYzFIQUVsM3hSeXN3VVJCS0xtSG80Uk1mdVE5?=
 =?utf-8?B?TmpTbjZ2MTZQbi94NGhJRmY4K0FIbWl0MHZKMXZxSGQ4VmdWcG1PVEdiMG1O?=
 =?utf-8?B?T09adVJ3b21JMTdRYlBRdElYZUpQVkxldmRsN1grRnYwTW1VZ2RSWk13QjFV?=
 =?utf-8?B?OUp1c3JaRjNtSXFKWFJ5QzNHTjU3NGhWZEdZSG5lYllsUXN6aWZmQzY0anli?=
 =?utf-8?B?ekJDb1VILzlJTS8rWTlsSG52dDQ4VjF4UVVjOG9HRXFzRlFWY3BwVmRtUmpv?=
 =?utf-8?B?d2REQXJoMVhZZnNibnovdlhJWGtwOE5QSUVJajdjNTZKZ29YU09DWHZCMnAv?=
 =?utf-8?B?SXFNUmZQTDVrTHZKVURpVUgrR2pId2s3RDd1SGQrYWFKUXFleURWUHNTajJ0?=
 =?utf-8?B?YTlzRUZqMkFEbkVhaEhwVVZhUkg1dkhrRHNwZXA0eWNZUmJZUjFXdkxZWFZi?=
 =?utf-8?B?aGN6TmIrbU5wT2JKaHFQZUlsN0hNSThvSnZqeEFuT3EwV0tGdnpHeVVzTkNh?=
 =?utf-8?B?SE5JeDQ0bTdLalJZQ3EzNmRJc283NXFtYVp5eTNYa25VUjZrU3BzeDlxMFU4?=
 =?utf-8?B?V3pkZXIvY2VCN0tWenhBYnZGd2N5RzVteGdKVzdWQmZtcGhZeUczYStjR3Jo?=
 =?utf-8?B?bzFGUHhtMmdKYzZwZU8reTdmMkVzczFreStqaURGUE5GZUt2Zk9qSXg1azkx?=
 =?utf-8?Q?eBmlUCj1s2Iaszb+mjlCzfWsa?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?utf-8?B?czFRellrcXRodDdISDFmUGFaZVdSdmZhRkpvK29PZU8wY2hEUnNRT041bjB0?=
 =?utf-8?B?NlJnMXVpbGNUTFY2Ty9KZU1BUkRvQm5EQTVBcGhrMUVtenY5V0tMcEk2OFRz?=
 =?utf-8?B?dTVuejV5SXZEbFdzR0oraXdqOHVLR1d6ajlwQVFqQ3BvVWVFWnhXOWhnYlc2?=
 =?utf-8?B?OWRQcDhYSVNzMGNGMm8zWE4xSm9yZ1dBQUtWbnJSVzU3ZFpkYllMRUpncUtu?=
 =?utf-8?B?Vzd4WWhHakxmaDVzaEpqRU9YMWJBeS9yUmNKME5Ea0pWeEpNNlFQT041ZFhn?=
 =?utf-8?B?MWl1SzZGWEVnZXJJZHVhREtvV09KbXIrL3NwWjNwNXUvUzY2Vk1NNE1CYkZN?=
 =?utf-8?B?clNwc21LVDZadzI0K2FvYVJwWlAzOVY3N2x0N1ZQamFNVDU4KzlGUkVOdVc1?=
 =?utf-8?B?c2lhNk9pRTdKNFdDYWxFdmNGeXdxWkRScGt4VHd2ZDJSWE1QOWpIMFFKTFFN?=
 =?utf-8?B?b0g5QW9JODZzaFR4M1lKaG8rbUlyV2F4YmcwcTRWZ29DZ2U2b1hXV05rTU9j?=
 =?utf-8?B?L3FhWHdZYjh1YVJ0Qk1hbXZMcUkyT2NpekRhb1MxdjVKemJNUWhjczBwOEJG?=
 =?utf-8?B?UmtPQi9Lak40TXhQQ0ZuTm9kYThjbEVuS1FZVU92TWNpRHlRNjlab1pzVWs5?=
 =?utf-8?B?SnQ1aExJbCttQS9BMEI1VGNsdmloQ1lrWkRLckpBREI4TjNIbVM2U0ZOVlVU?=
 =?utf-8?B?OTBENnB3YmkyZVJaaGtJK21iYnU0eFBZQWNtWFNwVU1QK24vbFM0ZVZLV2R1?=
 =?utf-8?B?SzQyNk5HcjhSc3crLzl3d2dCaTl5bk8xUXY0OVpNdXdib0VxME82RTZrdFZP?=
 =?utf-8?B?aThqMzhhTGpnazJWbW9xY1FVOXdub3cyT3VTbEVYZWg3RVBNV0d2a21ZUHdX?=
 =?utf-8?B?ZWxPYURDYkRkbXR5Y2ZHUmM2Q0hTbnlZQmhuZFpaSENpak9LZjZMd2xCNzB4?=
 =?utf-8?B?L1VqY3BZcjNSMzQzendUZFFjRnp6MExxQjFscGJOWFVXcWIwdUg1aWh6dmZT?=
 =?utf-8?B?UWRkU1RyS3JveW1PZUc2ZTZnUE1QZ2JlWTBjT2VHMGV5VHZqcFpxdHJTTUxQ?=
 =?utf-8?B?MnFPdlp4aG1nb3dOMEx3eVA1ZEF5ZGJSNzdpQ1d4aElyb2xHaXJWSm5lMUVS?=
 =?utf-8?B?OEhlNG1DOXMxU1BjRFJsY3J6YzNGSE9mMDdROG5rcDFDUE5CVVpIY3h4a3dx?=
 =?utf-8?B?NDVOWndjR3EzVk5XMWNyV05QaWY1WWZhVytKZnpxZ2RkNitvU0hCVTd4RzRR?=
 =?utf-8?B?dmRsdStDeEJQa0kwYmloSHoxR0x4cG16NUZjWGk0UjVVbTR6VCsyRlhRN1BL?=
 =?utf-8?B?SE9TOXN2RjdNcENEMFBBS2U2MUFkbElPQ2FUQldlSkNWN2ZiZklkZlRBOS9L?=
 =?utf-8?B?L2ZXbnJFSjhPTjlHa1hNbDVnUFVQRHRWamhkUU93UGo2NDY0Skt5SlJxQzZX?=
 =?utf-8?B?aUFCMUxDenJiUy82LzRJQjZ4MitXc3c5ZmJCMWxvVkd2RFRtbVFwRDJTTm0x?=
 =?utf-8?B?WEd3RXlFTzF4K0JlaWlEZ2RMZVFFOFRzMnNhYW40OTMxajRScmVaS2RXODZj?=
 =?utf-8?B?OVpEVW9hbWRtNFJNQVVYQnpBSmJjSXV2d0Nrdy9PSDYvNjdtbjQwUVJ4d3ZW?=
 =?utf-8?B?UVN0T1B3Wm1Sa1RMT3BDUDVmR0J1Y0I5VVVxZWE5TE9BQit2Y05uZjRtSUtF?=
 =?utf-8?B?MFB0d2lneCtGamtURzFxQWxkUXFkU1R6ZDhkVldBU3VDWUZuVlZqYWdsVUFN?=
 =?utf-8?Q?FbVKuATbJyIWWs0MtBS4QwBYevWqg7L2MTUCaGJ?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eb597fc5-26c8-4aa0-c8c6-08db473e2ff7
X-MS-Exchange-CrossTenant-AuthSource: CH3PR10MB6810.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2023 16:41:02.4475
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WDXL4wps3y/IjyLV8tP8bOK6sXUldbBFnmCU4Z9B2Dkf+MsoZ512GBoJT/L7q4arjajgffnlUZb9jQMTkMunYA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB6584
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-04-27_07,2023-04-27_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 bulkscore=0
 mlxlogscore=999 malwarescore=0 mlxscore=0 spamscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000
 definitions=main-2304270145
X-Proofpoint-GUID: 1y0FP_GQLfUcWQEXKCZyVZEt_T2CJvlv
X-Proofpoint-ORIG-GUID: 1y0FP_GQLfUcWQEXKCZyVZEt_T2CJvlv
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/26/23 15:27, Mike Kravetz wrote:
> On 04/26/23 10:49, Khalid Aziz wrote:
>> Memory pages shared between processes require a page table entry
>> (PTE) for each process. Each of these PTE consumes some of the
>> memory and as long as number of mappings being maintained is small
>> enough, this space consumed by page tables is not objectionable.
>> When very few memory pages are shared between processes, the number
>> of page table entries (PTEs) to maintain is mostly constrained by
>> the number of pages of memory on the system.  As the number of
>> shared pages and the number of times pages are shared goes up,
>> amount of memory consumed by page tables starts to become
>> significant. This issue does not apply to threads. Any number of
>> threads can share the same pages inside a process while sharing the
>> same PTEs. Extending this same model to sharing pages across
>> processes can eliminate this issue for sharing across processes as
>> well.
>>
>> Some of the field deployments commonly see memory pages shared
>> across 1000s of processes. On x86_64, each page requires a PTE that
>> is only 8 bytes long which is very small compared to the 4K page
>> size. When 2000 processes map the same page in their address space,
>> each one of them requires 8 bytes for its PTE and together that adds
>> up to 8K of memory just to hold the PTEs for one 4K page. On a
>> database server with 300GB SGA, a system crash was seen with
>> out-of-memory condition when 1500+ clients tried to share this SGA
>> even though the system had 512GB of memory. On this server, in the
>> worst case scenario of all 1500 processes mapping every page from
>> SGA would have required 878GB+ for just the PTEs. If these PTEs
>> could be shared, amount of memory saved is very significant.
> 
> When hugetlb pmd sharing was introduced the motivating factor was performance
> as much as memory savings.  See commit,
> 39dde65c9940 [PATCH] shared page table for hugetlb page
> 
> I have not verified the claims in that commit message, but it does sound
> reasonable.  My assumption is that the same would apply here.

Hi Mike,

Thanks for the feedback. I looked up the commit log for 39dde65c9940. You are right, same does apply here.

> 
>>
>> This patch series adds a new flag to mmap() call - MAP_SHARED_PT.
>> This flag can be specified along with MAP_SHARED by a process to
>> hint to kernel that it wishes to share page table entries for this
>> file mapping mmap region with other processes. Any other process
>> that mmaps the same file with MAP_SHARED_PT flag can then share the
>> same page table entries. Besides specifying MAP_SHARED_PT flag, the
>> processes must map the files at a PMD aligned address with a size
>> that is a multiple of PMD size and at the same virtual addresses.
>> This last requirement of same virtual addresses can possibly be
>> relaxed if that is the consensus.
> 
> I would think the same virtual address requirement is problematic in the
> case of ASLR.  hugetlb pmd sharing does not have the 'same virtual
> addresses' requirement.  My guess is that requiring the same virtual
> address does not make code simpler.

Same virtual address requirement make pevious mshare implementation quite a bit simpler, but this reimplementation in 
this RFC does not rely upon virtual addresses being same as much. This does open up the possibility of removing this 
requirement. I just haven't looked through any potential complications enough.

> 
>> When mmap() is called with MAP_SHARED_PT flag, a new host mm struct
>> is created to hold the shared page tables. Host mm struct is not
>> attached to a process. Start and size of host mm are set to the
>> start and size of the mmap region and a VMA covering this range is
>> also added to host mm struct. Existing page table entries from the
>> process that creates the mapping are copied over to the host mm
>> struct.
> 
> It seems there is one host mm struct per shared mapping.  Is that
> correct?  And, the host mm is the size of that single mapping?

There is one host mm per shared file. This was done to allow for multiple VMAs to exist in this mm for a file that can 
potentially represent multiple shared regions of the file. In the RFC, I am creating only one shared region per file for 
now.

> Suppose the following:
> - process A maps shared file offset 0 to 2xPMD_SIZE
> - process B maps shared file offset 0 to 2xPMD_SIZE
> It then makes sense A and B would use the same host mm.  Now,

Yes, that is correct.

> - process C maps shared file offset 0 to 4xPMD_SIZE
> Does C share anything with A and B?  Are there multiple host mm structs?

In the RFC implementation, C does not share anything with A. The code is written to allow for expansion to support this 
sharing as well as sharing multiple non-contiguous regions of the file. My goal is to debug and finalize sharing 
infrastructure for the simple case and then start expanding it. In this specific case, implementation would expand the 
existing shared VMAs to cover offset 0 to 4xPMD.

> 
> Just wondering at a high level how this would work without looking at
> the code.
> 
>>          All processes mapping this shared region are considered
>> guest processes. When a guest process mmap's the shared region, a vm
>> flag VM_SHARED_PT is added to the VMAs in guest process. Upon a page
>> fault, VMA is checked for the presence of VM_SHARED_PT flag. If the
>> flag is found, its corresponding PMD is updated with the PMD from
>> host mm struct so the PMD will point to the page tables in host mm
>> struct. vm_mm pointer of the VMA is also updated to point to host mm
>> struct for the duration of fault handling to ensure fault handling
>> happens in the context of host mm struct. When a new PTE is
>> created, it is created in the host mm struct page tables and the PMD
>> in guest mm points to the same PTEs.
>>
>> This is a basic working implementation. It will need to go through
>> more testing and refinements. Some notes and questions:
>>
>> - PMD size alignment and size requirement is currently hard coded
>>    in. Is there a need or desire to make this more flexible and work
>>    with other alignments/sizes? PMD size allows for adapting this
>>    infrastructure to form the basis for hugetlbfs page table sharing
>>    as well. More work will be needed to make that happen.
>>
>> - Is there a reason to allow a userspace app to query this size and
>>    alignment requirement for MAP_SHARED_PT in some way?
>>
>> - Shared PTEs means mprotect() call made by one process affects all
>>    processes sharing the same mapping and that behavior will need to
>>    be documented clearly. Effect of mprotect call being different for
>>    processes using shared page tables is the primary reason to
>>    require an explicit opt-in from userspace processes to share page
>>    tables. With a transparent sharing derived from MAP_SHARED alone,
>>    changed effect of mprotect can break significant number of
>>    userspace apps. One could work around that by unsharing whenever
>>    mprotect changes modes on shared mapping but that introduces
>>    complexity and the capability to execute a single mprotect to
>>    change modes across 1000's of processes sharing a mapped database
>>    is a feature explicitly asked for by database folks. This
>>    capability has significant performance advantage when compared to
>>    mechanism of sending messages to every process using shared
>>    mapping to call mprotect and change modes in each process, or
>>    using traps on permissions mismatch in each process.
> 
> I would guess this is more than just mprotect, and anything that impacts
> page tables.  Correct?  For example MADV_DONTNEED, MADV_HUGEPAGE,
> MADV_NOHUGEPAGE.

Yes. For instance, the RFC implementation allows one process to set MADV_DONTNEED and remove PTEs which removes them for 
all other processes sharing the mapping. That behavior does not quite sound right. A more robust implementation would 
possibly remove PTEs only if all sharing processes have set MADV_DONTNEED. Other flags might need different treatment, 
for instance MADV_WILLNEED should trigger read-ahead even if set by just one process.


> 
>> - This implementation does not allow unmapping page table shared
>>    mappings partially. Should that be supported in future?
>>
>> Some concerns in this RFC:
>>
>> - When page tables for a process are freed upon process exit,
>>    pmd_free_tlb() gets called at one point to free all PMDs allocated
>>    by the process. For a shared page table, shared PMDs can not be
>>    released when a guest process exits. These shared PMDs are
>>    released when host mm struct is released upon end of last
>>    reference to page table shared region hosted by this mm. For now
>>    to stop PMDs being released, this RFC introduces following change
>>    in mm/memory.c which works but does not feel like the right
>>    approach. Any suggestions for a better long term approach will be
>>    very appreciated:
>>
>> @@ -210,13 +221,19 @@ static inline void free_pmd_range(struct mmu_gather *tlb,
>> pud_t *pud,
>>
>>          pmd = pmd_offset(pud, start);
>>          pud_clear(pud);
>> -       pmd_free_tlb(tlb, pmd, start);
>> -       mm_dec_nr_pmds(tlb->mm);
>> +       if (shared_pte) {
>> +               tlb_flush_pud_range(tlb, start, PAGE_SIZE);
>> +               tlb->freed_tables = 1;
>> +       } else {
>> +               pmd_free_tlb(tlb, pmd, start);
>> +               mm_dec_nr_pmds(tlb->mm);
>> +       }
>>   }
>>
>>   static inline void free_pud_range(struct mmu_gather *tlb, p4d_t *p4d,
>>
>> - This implementation requires an additional VM flag. Since all lower
>>    32 bits are currently in use, the new VM flag must come from upper
>>    32 bits which restricts this feature to 64-bit processors.
>>
>> - This feature is implemented for file mappings only. Is there a
>>    need to support it for anonymous memory as well?
> 
> I have not looked at the implementation, are 'file mappings' only
> mappings using the page cache?  Or, do you just need a file descriptor?
> Would a file descriptor created via memfd_create work for anonymous
> memory?
> 

I look for just a file pointer, so an fd created by memfd would work for anonymous memory.

Thanks,
Khalid