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 4C95FC05027 for ; Mon, 20 Feb 2023 03:04:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47DEA6B0071; Sun, 19 Feb 2023 22:04:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 42DDE6B0072; Sun, 19 Feb 2023 22:04:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31CDE6B0073; Sun, 19 Feb 2023 22:04:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 213916B0071 for ; Sun, 19 Feb 2023 22:04:28 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DEAEB80D2B for ; Mon, 20 Feb 2023 03:04:27 +0000 (UTC) X-FDA: 80486176974.11.81E715A Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf10.hostedemail.com (Postfix) with ESMTP id 40F80C0004 for ; Mon, 20 Feb 2023 03:04:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EGWICy9w; spf=none (imf10.hostedemail.com: domain of yuan.yao@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=yuan.yao@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676862266; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ES0szear+BlPFpvjct07fk9Tite0T1MaXVQ6zfdni2o=; b=tc1raf75uzvuISx/Y5lGsL2SPK+klmJBndV3FGqJCkmLhtXvSjxq29VZnbl/5pPg3OUZwY cZQzqXqBWAQ44FFwvNaeevn07BKU23AJzs+790Eu6PxXmUACzsb1DB4XKSo41L3bQTPVJG ji2568bHr+McvytUuRqGDcHxb+s1BV4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EGWICy9w; spf=none (imf10.hostedemail.com: domain of yuan.yao@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=yuan.yao@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676862266; a=rsa-sha256; cv=none; b=YM1t8uPdZ5Hz5cQ/tHTkKmfbpzgu3ANB5dKAIRkNjJqN5iKgvtE3vVkdGF19QwRiAq0eGj mOOpvrRsEMOfSKmFRXnXYiN43qUFfP3O76Z1i3XCnHqoF+ZG0WZbMjFoUnhHO/zSoqtHaV Z5+WIG81s5pTEWdpxYWQFGrY7+pFZdc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676862265; x=1708398265; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=E8xZ7auVU/piWMLG1AXlZIsK3dlj5WYN4ckwufDorRE=; b=EGWICy9wMH9YJYpgELzcRAX33oMBi6cvJ/1T5YOM7AKEoVx4wKfz0BDs QlLkkNjKx+87nqUYs8/MrFlJAXxKfSrrcJLUp3heFVMGVm3+WhE3pgab/ Ukl3PKKkvV4iasDPByEKmML8Fod7DOePMYFMF6Ha1C9mXYOWvEhmKIyQx +bfKjcX9/U09Af27aATRFmEqIKxGAAgyLbFtxO7pY/0f6jqmLWjFLvjrd qlC8+iuVCa5sT7zQxH7zT+paeqIQohJsWS6wOvduA6/T3q90skM9ufdNq 00HctffZDEDXJdzFBR+iwjtJTjg+TnC55uem1+p99L59AlANHwJmIv9bR Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10626"; a="332319337" X-IronPort-AV: E=Sophos;i="5.97,311,1669104000"; d="scan'208";a="332319337" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2023 19:04:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10626"; a="1000125665" X-IronPort-AV: E=Sophos;i="5.97,311,1669104000"; d="scan'208";a="1000125665" Received: from yy-desk-7060.sh.intel.com (HELO localhost) ([10.239.159.76]) by fmsmga005.fm.intel.com with ESMTP; 19 Feb 2023 19:04:13 -0800 Date: Mon, 20 Feb 2023 11:04:12 +0800 From: Yuan Yao To: Ackerley Tng Cc: kvm@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, qemu-devel@nongnu.org, aarcange@redhat.com, ak@linux.intel.com, akpm@linux-foundation.org, arnd@arndb.de, bfields@fieldses.org, bp@alien8.de, chao.p.peng@linux.intel.com, corbet@lwn.net, dave.hansen@intel.com, david@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, hpa@zytor.com, hughd@google.com, jlayton@kernel.org, jmattson@google.com, joro@8bytes.org, jun.nakajima@intel.com, kirill.shutemov@linux.intel.com, linmiaohe@huawei.com, luto@kernel.org, mail@maciej.szmigiero.name, mhocko@suse.com, michael.roth@amd.com, mingo@redhat.com, naoya.horiguchi@nec.com, pbonzini@redhat.com, qperret@google.com, rppt@kernel.org, seanjc@google.com, shuah@kernel.org, steven.price@arm.com, tabba@google.com, tglx@linutronix.de, vannapurve@google.com, vbabka@suse.cz, vkuznets@redhat.com, wanpengli@tencent.com, wei.w.wang@intel.com, x86@kernel.org, yu.c.zhang@linux.intel.com Subject: Re: [RFC PATCH 0/2] Add flag as THP allocation hint for memfd_restricted() syscall Message-ID: <20230220030412.fgh3f5qzgihz4f4x@yy-desk-7060> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 X-Stat-Signature: hby3fexp15ayihat7pfg3decw8m1u6t3 X-Rspam-User: X-Rspamd-Queue-Id: 40F80C0004 X-Rspamd-Server: rspam06 X-HE-Tag: 1676862264-938192 X-HE-Meta: U2FsdGVkX1+d2vi4pbKZqh2y/I8IITwBiSXU/VXO+5TRykNKXZglvOlrKZcoAp/hi1rf6vLNIIXH9RiNnPFxgarmbHE8X/0aw7gBRXM4tDlIBb+s3b8UcFMY15EHFWpSWR4FHg75+L5rgX/hgVaGwM5UzXO85GVUQkWIEWJbDMSXaMFXX1ZDpDRNFxhU8WerLInEomHU8nPIaV4smcVJ41APdqSnRORvNxX0fJL1b1EgTf4Qhwu8XV8urGtmvc3aJIvCe14sg1hweG2WzrRTQgDk+0IbGI4HrB/1aMqKhYQn8aarz/rRunV3T66ffwZAy8fkMeVi57jQ7k8TJazpnRH0kiW97tpB/lfujgjBUqkXgsmND7BUrmDOcLTGp6uYZ6le9CHPWhp/TlrQH+3qz9YSd8ltU3QzKq8LJKk4z7AYo6Jxyj0DazPDTFwEpI9SPmt/Z0ZW6NZByWpXHmTjW9t+Qk8ShN+hKnWUqSD3SQy3MzBqV0ydbI1GiBwR8xB43wtnFEyzGNHbqOa6MnTBW4GOHR5bo4BQIiU4zLYvS/yd4NB+jkFgUkVxMu1xwmCnK5WhrgmtsAAx2g0gzIHU6/62RIMg8BeDWEPE4bUysRim/MQ9kxh8wEwFxvj5IIIVZhAipqLeXDvj0F3Hn+c9s/swBQB+FZ2GhePqq7Gs4nGz8D1Yx8Nc5wRwektYxseb+gFQeGu5WcGxAZieGUYUAtPGAako8Z94ancPFRcv3obLJjzWtniw1j/iE3zEV0N4yK9yMN0l8Se+06Qos8NzXJypDum4VtvnS1Htrsc0nQOw+cAPoclEE2A5jAmgnrdgejVuzgnd/0sUcqHpuwa+UssRPF/Oggv1l5H9trz68a+REL4irD02lHmdkexs0DM/gVqNu0ZtqVIlT2OUahp56+nG1THkRtKVHpRo2nXSVs7Hd8lk/sEmWdMifjXe1RtiBPB2bQ3Ho0ns8b1nrwN 2NCrLT3S Cu6JDWVFyqfThE2Dq/FD2JFoJ7U147MJPQE27EN1yC8Tc1wwpoTz9wVQDR8Qym3/TlcgFi5Jzc3QKsNFfL0TeiIz9RYSJMTOBSkuV0PFnwiJpbDBySvK40yMl6SpXvH82UwLrVC4P7RtaYvnU7qn5nz8u0HCoeIVqketUEp/QuDMaEBlwXK4cr8KIkSno1JTyA8ubktODTLarONMo+ehRzgPAE/1BCsI7oMsfJdrBtdXPdspcLCD1yZOwml4I4Y902SRH0dDh8qge+5LXlHhfLKDkMXtMG7TBjrL4WYdXX2twVXv9Ov9eEqv9WyEv+fzqz5gF3EKGrNmf49pd8ReVZBiFnqm9pDfoVOdYt/ORTa4IYBjE/QrkzezikChkpNvI/u/CcQkYn5PSrKRJP/zNHE+EshJGxgO/mrbSUiBMjHxRrRU= 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 Sat, Feb 18, 2023 at 12:43:00AM +0000, Ackerley Tng wrote: > Hello, > > This patchset builds upon the memfd_restricted() system call that has > been discussed in the ‘KVM: mm: fd-based approach for supporting KVM’ > patch series, at > https://lore.kernel.org/lkml/20221202061347.1070246-1-chao.p.peng@linux.intel.com/T/#m7e944d7892afdd1d62a03a287bd488c56e377b0c > > The tree can be found at: > https://github.com/googleprodkernel/linux-cc/tree/restrictedmem-rmfd-hugepage > > Following the RFC to provide mount for memfd_restricted() syscall at > https://lore.kernel.org/lkml/cover.1676507663.git.ackerleytng@google.com/T/#u, > this patchset adds the RMFD_HUGEPAGE flag to the memfd_restricted() > syscall, which will hint the kernel to use Transparent HugePages to > back restrictedmem pages. > > This supplements the interface proposed earlier, which requires the > creation of a tmpfs mount to be passed to memfd_restricted(), with a > more direct per-file hint. > > Dependencies: > > + Sean’s iteration of the ‘KVM: mm: fd-based approach for supporting > KVM’ patch series at > https://github.com/sean-jc/linux/tree/x86/upm_base_support > + Proposed fix for restrictedmem_getattr() as mentioned on the mailing > list at > https://lore.kernel.org/lkml/diqzzga0fv96.fsf@ackerleytng-cloudtop-sg.c.googlers.com/ > + Hugh’s patch: > https://lore.kernel.org/lkml/c140f56a-1aa3-f7ae-b7d1-93da7d5a3572@google.com/, > which provides functionality in shmem that reads the VM_HUGEPAGE > flag in key functions shmem_is_huge() and shmem_get_inode() Will Hugh's patch be merged into 6.3 ? I didn't find it in 6.2-rc8. IMHO this patch won't work without Hugh's patch, or at least need another way, e.g. HMEM_SB(inode->i_sb)->huge. > > Future work/TODOs: > + man page for the memfd_restricted() syscall > + Support for per file NUMA binding hints > > Ackerley Tng (2): > mm: restrictedmem: Add flag as THP allocation hint for > memfd_restricted() syscall > selftests: restrictedmem: Add selftest for RMFD_HUGEPAGE > > include/uapi/linux/restrictedmem.h | 1 + > mm/restrictedmem.c | 27 ++++++++++++------- > .../restrictedmem_hugepage_test.c | 25 +++++++++++++++++ > 3 files changed, 43 insertions(+), 10 deletions(-) > > -- > 2.39.2.637.g21b0678d19-goog >