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 03B5CC433FE for ; Thu, 17 Nov 2022 06:30:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 305A16B0073; Thu, 17 Nov 2022 01:30:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B6278E0002; Thu, 17 Nov 2022 01:30:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17D0E6B0075; Thu, 17 Nov 2022 01:30:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 04DD26B0073 for ; Thu, 17 Nov 2022 01:30:40 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C735F160B88 for ; Thu, 17 Nov 2022 06:30:39 +0000 (UTC) X-FDA: 80141960598.21.600E7C7 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf16.hostedemail.com (Postfix) with ESMTP id A4320180009 for ; Thu, 17 Nov 2022 06:30:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668666638; x=1700202638; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=/+HBrrsfrVpXa8wSoQRFbTPEIvOcBtvT7BZKCLGSfzI=; b=AyUbpCB3/zWApnJSrlH8XGJdexIt2QAmf0H3Bp6C6icSiww0lEU6qv7z RSy5xpbLb2y/zB1DkaDbZuYF8e+PyjHi1CGI3nRQJwoNx9NJ7XgzDSC1V sDpeHIHzJdEjyZladgWjbkzb3qZ2hEbDYARDNhbz6ACd/GanO9eHS8p3A xNIIdCkfrsZmFWz2BqvPnVA0yXBAxY8MlPcJtRQn1tBuYNjmte64YSOsa TZpld1skqzRrMgHS4uobtQ2uc/Z03wjmh0AQLlLHaSVYriToabSLULVNU zHJY1i14NE2yDvFPmZOhOZC8X8luFjhza1/kwxRsnzmIqaWvFDOiSDwNM w==; X-IronPort-AV: E=McAfee;i="6500,9779,10533"; a="310401824" X-IronPort-AV: E=Sophos;i="5.96,169,1665471600"; d="scan'208";a="310401824" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Nov 2022 22:30:36 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10533"; a="639674849" X-IronPort-AV: E=Sophos;i="5.96,169,1665471600"; d="scan'208";a="639674849" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Nov 2022 22:30:34 -0800 From: "Huang, Ying" To: Michal Hocko Cc: Zhongkun He , corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [External] Re: [PATCH v2] mm: add new syscall pidfd_set_mempolicy(). In-Reply-To: (Michal Hocko's message of "Wed, 16 Nov 2022 10:44:15 +0100") References: <20221111084051.2121029-1-hezhongkun.hzk@bytedance.com> <87zgcrwfac.fsf@yhuang6-desk2.ccr.corp.intel.com> <0445de39-15a4-f645-b380-39f20abb6524@bytedance.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Thu, 17 Nov 2022 14:29:36 +0800 Message-ID: <87mt8qw0tr.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668666639; a=rsa-sha256; cv=none; b=IXxkwnttXUCNJOMVg1kojnO5sOxNj0NaLahD69ZEHUE5Xx8iNJXdc2MvW7ur/moGRNp+I3 or5NdMx1LWQIi2ac0kDBt2pDw3QYQ5N7RrxMgj6zOkkHnb4z4UxfYNl71HKrXJ9EimCLmV 8qFJcKljbV5phQElIrYZpq6zSZXZ1Js= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=AyUbpCB3; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668666639; 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=wqaWfQHuBhDNOm0fnyES+nXYjjlaRCQtMeXjD1Y9n1s=; b=5mhSatzQR/Jk+XIWdnFUJ/qeeiMphNsvFrL3syzG1QQP6A6Qy42L4MC7MIf3ClwtEhaNK8 2VDsM3eF3rTGXWLwJxwS+FoS4AxLRvmvZtrD/iQSnJkcvCT/Ij3kItfSUzXoJaJcxQschP 2O/9TshcFK1sxMMxHmG7votil7X0HaA= X-Rspamd-Queue-Id: A4320180009 Authentication-Results: imf16.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=AyUbpCB3; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: yxmp7tpcykcqmm891j78r99eyfjyake3 X-HE-Tag: 1668666638-283744 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: Michal Hocko writes: > On Wed 16-11-22 17:38:09, Zhongkun He wrote: >> Hi Ying, thanks for your replay and suggestions. >> >> > >> > I suggest to move the flags in "mode" parameter (MPOL_F_STATIC_NODES, >> > MPOL_F_RELATIVE_NODES, MPOL_F_NUMA_BALANCING, etc.) to "flags" >> > parameter, otherwise, why add it? >> >> The "flags" is used for future extension if any, just like >> process_madvise() and set_mempolicy_home_node(). >> Maybe it should be removed. > > No, please! Even if there is no use for the flags now we are usually > terrible at predicting future and potential extensions. MPOL_F* is kinda > flags but for historical reasons it is a separate mode and we shouldn't > create a new confusion when this is treated differently for pidfd based > APIs. > >> > And, how about add a "home_node" parameter? I don't think that it's a >> > good idea to add another new syscall for pidfd_set_mempolicy_home_node() >> > in the future. > > Why would this be a bad idea? > >> Good idea, but "home_node" is used for vma policy, not task policy. >> It is possible to use it in pidfd_mbind() in the future. > > I woould go with pidfd_set_mempolicy_home_node to counterpart an > existing syscall. Yes. I understand that it's important to make API consistent. Just my two cents. >From another point of view, the new API gives us an opportunity to fix the issues in existing API too? For example, moving all flags into "flags" parameter, add another parameter "home_node"? Maybe we can switch to this new API in the future completely after finding a way to indicate "current" task in "pidfd" parameter. Best Regards, Huang, Ying