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 247DDC4321E for ; Fri, 2 Dec 2022 13:44:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91D7E6B0074; Fri, 2 Dec 2022 08:44:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A61D6B0075; Fri, 2 Dec 2022 08:44:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7203C6B0078; Fri, 2 Dec 2022 08:44:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5FA916B0074 for ; Fri, 2 Dec 2022 08:44:39 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E6D1A12065C for ; Fri, 2 Dec 2022 13:44:38 +0000 (UTC) X-FDA: 80197486236.29.FFED9D7 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf24.hostedemail.com (Postfix) with ESMTP id CC2A6180016 for ; Fri, 2 Dec 2022 13:44:36 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=etrl713u; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669988677; 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=V3DTtz+t5FOU4bKwX28Uhr0yS0o/KdcIIao94APWIXE=; b=nKilakNcwagwlOg2D+tlIRZWkwpYDR/IWbV6K1i29xshSCqJzInT7AVx9DgDNxCq6Lkox0 C85zHqNtY/nj7XSyaU0iNsF2PGDcOYun1RpA0GKqw2XnboILCjkjliT0tIcq4hIwlj5mKq UFfEYs7pUzzVfR0Pfg6iL0x3h+nam+Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669988677; a=rsa-sha256; cv=none; b=aa4KvHnBDxVMQSTA+qrpZ7V7QgKHl+fHRIJsA1icrLexmU/vP0ICQfMB0jlTOvVEHsChbg lCyqavHff0xbYLKqrpBeFnTmT5O6KraZKPStLY8Gf6DjA+GoRwRWqfueXDckVcW5/q34uQ E4t5k6gw/2eIDnG3WJvvHQGL/HbFgcE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=etrl713u; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669988676; x=1701524676; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=skS3MR2BvQKKKmac1ZclTHHuTXnPM7lSX4PdHSON5iM=; b=etrl713uP9zPN4Y7zzOnpu5bmc+dZ/UHIghKHo1yCxupTaAkrFTKUBaY t4oc46tu8uZ8kkVhwqlV5wk7FYmCZTp4bn4DU0qR1fvvbnCoLMwOTcQwY KyWPe1dM3gcRzgCwwsJW2Pvn8B36fT+vL8QwXI3zGWuGYWkSaKUDeJGmI XcOKz0oM4NmX6dqQuXhEBmtqARggoMic/rL4G6ljl0i4ujXm+hJ6AetCw yBSO/kCPQzE9EobLmy0B/Kk9u4MlqrjSReB22I6yUPeJVVAwP4nEtu4ue 1OhcApdKlizefoDn8GRmuom3izr80PksleDMf4MA10VloV3880DgajFx9 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="317102456" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="317102456" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 05:44:35 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="622704069" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="622704069" Received: from valeriya-mobl2.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.211.234]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 05:44:23 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id EC5D610975F; Fri, 2 Dec 2022 16:44:19 +0300 (+03) Date: Fri, 2 Dec 2022 16:44:19 +0300 From: "Kirill A . Shutemov" To: Chao Peng Cc: Vishal Annapurve , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Sean Christopherson , 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 , tabba@google.com, Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 1/8] mm: Introduce memfd_restricted system call to create restricted user memory Message-ID: <20221202134419.vjhqzuz5alv3v2ak@box.shutemov.name> References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-2-chao.p.peng@linux.intel.com> <20221202064909.GA1070297@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221202064909.GA1070297@chaop.bj.intel.com> X-Stat-Signature: uapgbmmnh61soseo9brsnf7dddnjh8rh X-Spamd-Result: default: False [-2.35 / 9.00]; BAYES_HAM(-2.65)[98.46%]; SUBJECT_HAS_UNDERSCORES(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; R_DKIM_ALLOW(-0.20)[intel.com:s=Intel]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWELVE(0.00)[46]; DKIM_TRACE(0.00)[intel.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: CC2A6180016 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1669988676-203933 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, Dec 02, 2022 at 02:49:09PM +0800, Chao Peng wrote: > On Thu, Dec 01, 2022 at 06:16:46PM -0800, Vishal Annapurve wrote: > > On Tue, Oct 25, 2022 at 8:18 AM Chao Peng wrote: > > > > ... > > > +} > > > + > > > +SYSCALL_DEFINE1(memfd_restricted, unsigned int, flags) > > > +{ > > > > Looking at the underlying shmem implementation, there seems to be no > > way to enable transparent huge pages specifically for restricted memfd > > files. > > > > Michael discussed earlier about tweaking > > /sys/kernel/mm/transparent_hugepage/shmem_enabled setting to allow > > hugepages to be used while backing restricted memfd. Such a change > > will affect the rest of the shmem usecases as well. Even setting the > > shmem_enabled policy to "advise" wouldn't help unless file based > > advise for hugepage allocation is implemented. > > Had a look at fadvise() and looks it does not support HUGEPAGE for any > filesystem yet. Yes, I think fadvise() is the right direction here. The problem is similar to NUMA policy where existing APIs are focused around virtual memory addresses. We need to extend ABI to take fd+offset as input instead. -- Kiryl Shutsemau / Kirill A. Shutemov