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 1BCD3ECAAA1 for ; Mon, 24 Oct 2022 14:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CC4F940008; Mon, 24 Oct 2022 10:59:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85557940007; Mon, 24 Oct 2022 10:59:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F5BF940008; Mon, 24 Oct 2022 10:59:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5DD08940007 for ; Mon, 24 Oct 2022 10:59:44 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3866EA08BD for ; Mon, 24 Oct 2022 14:59:44 +0000 (UTC) X-FDA: 80056152288.15.925CA62 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf10.hostedemail.com (Postfix) with ESMTP id 03AC2C0031 for ; Mon, 24 Oct 2022 14:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666623583; x=1698159583; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=f12+hDSs2xhh9+cgFUHAQwPz5EdOX4nrGTxSpB9xto8=; b=MYr6Xyn7vbb3ghCsaa+nuVERWhGESOEdmflCI0rwTWbGUYboU9kvou1g d3jd3cMmTBdSSKxvhpMV9VfBEutKZmFEsicRGbHxEaL2X1GkJJp0pwieb TyekFUPPPqoQYZxyDxHtAZoLiYHQizVm2iDYQ2oabJS051UXBoEtJa1YK uW8yJSMdLm3AGqQ2p8uFUL716CbCDf9HCCaqJiHe9oIb8ulyZISe9FPxa W4MnMKJTahbhdCBb7li9gWKz13IX234C8Qp85HX1Ig9oqGrtUMsAx0OEP bzLVah2bkGmWutiDXXgGeOZcZBE29QVXYxxAC+vsmVsZ1emurGropig3Y g==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="393753937" X-IronPort-AV: E=Sophos;i="5.95,209,1661842800"; d="scan'208";a="393753937" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 07:59:41 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="631284461" X-IronPort-AV: E=Sophos;i="5.95,209,1661842800"; d="scan'208";a="631284461" Received: from unisar-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.249.38.228]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 07:59:30 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 381A7104D5C; Mon, 24 Oct 2022 17:59:28 +0300 (+03) Date: Mon, 24 Oct 2022 17:59:28 +0300 From: "Kirill A . Shutemov" To: Sean Christopherson Cc: Chao Peng , Vishal Annapurve , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Yu Zhang , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd Message-ID: <20221024145928.66uehsokp7bpa2st@box.shutemov.name> References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-2-chao.p.peng@linux.intel.com> <20221021134711.GA3607894@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=MYr6Xyn7; spf=none (imf10.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666623583; a=rsa-sha256; cv=none; b=rvDmz0ND7uUBw5JkfCdVC56mhh2kWh8CKK6KPQY73YXxF+yNFRw39YgKytSoMRLRmV9NtI VtY3veBb0eZ0FNw8/odAYIOtJIG96FE7skxTDMrnoK3H3HB1RfUnYev37asOxtO/o8PvGZ O6RPeNjbP4d53Nn4YrbpDZKnV5dtimY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666623583; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0LHZTihi5e0ZbPynkVtYLOQCyy7ig/jvQpdRuGUkieM=; b=HPX/ihD8AtxqYpus9+nfG/GeFdVmRYY5NV04ynjSnv8Vg1GDhSSaIt+4HmvsVOuEOHsKa9 FTKIDaLhteyYsFtQ16vpepw1x99673MvVooRgCpLzokDi9Jmaq2VM2qfP+Qhs546zZJzeC QXT6RrSazDvjr35B7FPq0du0ujn5JSw= Authentication-Results: imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=MYr6Xyn7; spf=none (imf10.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Stat-Signature: 55iopmmizyk8xr4ohj8a6mkug48i9kt4 X-Rspamd-Queue-Id: 03AC2C0031 X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1666623582-626536 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 Fri, Oct 21, 2022 at 04:18:14PM +0000, Sean Christopherson wrote: > On Fri, Oct 21, 2022, Chao Peng wrote: > > > > > > In the context of userspace inaccessible memfd, what would be a > > > suggested way to enforce NUMA memory policy for physical memory > > > allocation? mbind[1] won't work here in absence of virtual address > > > range. > > > > How about set_mempolicy(): > > https://www.man7.org/linux/man-pages/man2/set_mempolicy.2.html > > Andy Lutomirski brought this up in an off-list discussion way back when the whole > private-fd thing was first being proposed. > > : The current Linux NUMA APIs (mbind, move_pages) work on virtual addresses. If > : we want to support them for TDX private memory, we either need TDX private > : memory to have an HVA or we need file-based equivalents. Arguably we should add > : fmove_pages and fbind syscalls anyway, since the current API is quite awkward > : even for tools like numactl. Yeah, we definitely have gaps in API wrt NUMA, but I don't think it be addressed in the initial submission. BTW, it is not regression comparing to old KVM slots, if the memory is backed by memfd or other file: MBIND(2) The specified policy will be ignored for any MAP_SHARED mappings in the specified memory range. Rather the pages will be allocated according to the memory policy of the thread that caused the page to be allocated. Again, this may not be the thread that called mbind(). It is not clear how to define fbind(2) semantics, considering that multiple processes may compete for the same region of page cache. Should it be per-inode or per-fd? Or maybe per-range in inode/fd? fmove_pages(2) should be relatively straight forward, since it is best-effort and does not guarantee that the page will note be moved somewhare else just after return from the syscall. -- Kiryl Shutsemau / Kirill A. Shutemov