Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp7226900rwi; Mon, 24 Oct 2022 11:29:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7C0jOyiT6wzcSd3vpV2ELfpJTKaxOAdP2PlJ++hemtVciHZeVcwzwq0/ukg6ELB5+Ntz4/ X-Received: by 2002:a17:907:1629:b0:79d:aa05:3783 with SMTP id hb41-20020a170907162900b0079daa053783mr14630244ejc.637.1666636173858; Mon, 24 Oct 2022 11:29:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666636173; cv=none; d=google.com; s=arc-20160816; b=lIfz/lBRFLRNIBoFNPAZ3PG/WtUNoSl+6bLP/4lM2agFa22eKpmbNdMxvoKhBhE/tv UcXKAD4/Ig8D/pumxqO7fpNzhFmGibBUPF9xc+gs5tzFJzyLojlyhK8npK4zLlWF4h9Q 3Y00eNudL3nM5QXCv1UKfBv9oVXkMmK/m78bSuACuS359Jv/Mcy6WPGoZcopj8ZYgLR6 +4lm0SnzQtur5qkY89Bf9oPSgR/py/Im7pgPNNMcK0CAE3kXww9h9WVVO7KdQhNPMMhK /JbcJF32NU/+yAdhcj+fRaLnO6k5R8sobdJ8ACy7UZpZancTr/vGnDFNU5WEdkiSV4y7 KtqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0LHZTihi5e0ZbPynkVtYLOQCyy7ig/jvQpdRuGUkieM=; b=1Lug0mzxTKXSaICKvmGbwASZclFJHTDSq/fymKkGK3S1Cs7rrI8LbgyOmldZw8O1Ro rhOi2FIEEGhYdya80nfgqPpsteF1iXXkOf6AiZvr3PpMVFXpCqXXbWJOfUheJk01wnBO bdXbbf2He9RyRefKgaJ8jKg4+JCkSU9wikbOw94ZlSGiuNKNh0fJoBxKmP09R4Lfjzzr Nv1P18YyYJ9n+4r6wMqZbC4/LbLC9WSqa4F5CxnqIiIjtIn0F26SwM4b86UW+ZeQDttO a4k3Cq4OrYeutJYG2eZG0GJdMsRrJZ3M0ihK5QKc9ftLQbh+Xv6qS3j3K/yv3jYl1Cx6 ny7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Lx4O7B4H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b15-20020a056402278f00b0045907cec72dsi509677ede.320.2022.10.24.11.29.08; Mon, 24 Oct 2022 11:29:33 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Lx4O7B4H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230267AbiJXSNG (ORCPT + 99 others); Mon, 24 Oct 2022 14:13:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231936AbiJXSMW (ORCPT ); Mon, 24 Oct 2022 14:12:22 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 461B757E17; Mon, 24 Oct 2022 09:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666630459; x=1698166459; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=f12+hDSs2xhh9+cgFUHAQwPz5EdOX4nrGTxSpB9xto8=; b=Lx4O7B4HXPSw6eCOX6fxKVKroy/kLcxL2hy81b68CBxeeJRyLCmgMCfL +GmcUQtQfNoaO0aKDUWtL30YejrZoBatDCS3PeFJE4DrVZy75n4meLb3V lTd9rYHhJuaupDbeWYGNYIRyNXZj3pq47viEZfMgcU99FnPK0/qZgfmIi gspbcVr59orDB9o72YPvLlrDzWGOkCq17RmNQJRAMNg2/pBM0j0LNOMfA bj+i/Q+CUyf8nP7jn5Mf5krunxQliQkthbAZqVw/QMtNgTnCY5KYq20Fa rnUMOQajJskrGGHNEtBU+aDreoW/sfo7JqEpyO72zuy8iUIvlJ76mj0/t A==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="290739879" X-IronPort-AV: E=Sophos;i="5.95,209,1661842800"; d="scan'208";a="290739879" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.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: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org 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