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 6EC68C4167B for ; Wed, 13 Dec 2023 02:46:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 826F46B0336; Tue, 12 Dec 2023 21:46:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 787206B0338; Tue, 12 Dec 2023 21:46:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56BFA6B033A; Tue, 12 Dec 2023 21:46:49 -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 303F86B0336 for ; Tue, 12 Dec 2023 21:46:49 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0A1E5A1E13 for ; Wed, 13 Dec 2023 02:46:49 +0000 (UTC) X-FDA: 81560257338.01.62A2504 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by imf17.hostedemail.com (Postfix) with ESMTP id A90A84000E for ; Wed, 13 Dec 2023 02:46:46 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TUDw4XP7; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@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=1702435607; 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=TAHveQN+UOYGQM+UNhNCN/zVlJ+0jIhH3fuXYMIo4D4=; b=Pagu1nb3zheKVAEnvQJ+N/1tKPxEAJF3I5oJzmhFFN7pY1fbuOQjoF9WDs5et/7Ruq6Im0 R1Oojrat7XO8Br0lPQCOQ7oB6ocVRUeCPF+7OjZ9+IlEa/lHumVkWMpGno5/y+AKOO9gGt dLK2GuoT5MDow3rcW6iDFpaZPjX6S/k= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TUDw4XP7; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702435607; a=rsa-sha256; cv=none; b=urkBr7QrNo3hd/wiXxGTNElwubohIhYtVGvLTAMir0LB9O8uuEOTvm8BkdSkz3IB5qAMOP +7y7nTj5OGp0g2txRMpaR8iJLaLNB/DQeieQ8HDu0Q0rKEsVRRjLZobGHkx8XOlvCrEFPW H7omp4smydfHBv/ZBw5NexFjVtMGmf4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702435607; x=1733971607; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=HeA8jqVHlKL8RuAwlVwqlEfSLUf01LuyOK0z4h52XBU=; b=TUDw4XP7usWCSEMJdFUiQTq129JKcQmj6XU0hlBXuWf5LTz5/HIWLRgc YKk3ZRLY7yhB/UZxbqPPgxRMWgZnD4ihIbrJ8MCH85QEXV4ZQKuZMJtyM qf4dstpzg91aN4kvilVj+8VIcuN13QQj0xJxXbG82/2ltsiPT9WNJmkJM XzakyCi7b0RPFEHZxiuytxCuup2eTeSQjnUscypXyWDz5/ipjfW4Ip1Rs 4rDc5wismP/EhlhO1VF/6EeW+sgrwiRhS97l4QTmR91ajW6rQhZTmc0WO YXvdPRH115D2xAWV/Cat1AWbLMLouTKPZzB7QGEJUl6dk6bxFPyJS/kZN g==; X-IronPort-AV: E=McAfee;i="6600,9927,10922"; a="8281570" X-IronPort-AV: E=Sophos;i="6.04,271,1695711600"; d="scan'208";a="8281570" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2023 18:46:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10922"; a="808005595" X-IronPort-AV: E=Sophos;i="6.04,271,1695711600"; d="scan'208";a="808005595" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2023 18:46:35 -0800 From: "Huang, Ying" To: Gregory Price Cc: Gregory Price , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Johannes Weiner , "Hasan Al Maruf" , Hao Wang , Dan Williams , Michal Hocko , Zhongkun He , Frank van der Linden , "John Groves" , Jonathan Cameron Subject: Re: [PATCH v2 00/11] mempolicy2, mbind2, and weighted interleave In-Reply-To: (Gregory Price's message of "Tue, 12 Dec 2023 10:59:06 -0500") References: <20231209065931.3458-1-gregory.price@memverge.com> <87r0jtxp23.fsf@yhuang6-desk2.ccr.corp.intel.com> <87plzbx5hz.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 13 Dec 2023 10:44:35 +0800 Message-ID: <87zfyestws.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: A90A84000E X-Rspam-User: X-Stat-Signature: g9etxxpoymu57c3oqqbzs9yfhruo8fiw X-Rspamd-Server: rspam01 X-HE-Tag: 1702435606-731367 X-HE-Meta: U2FsdGVkX18vyvB+R2CiQpNZ4ZkxlIk1FrRNKbpCFtXYeAMlHTpl8b1IwhYaJo8oyVzU65wRTdWlNG/FR29Gh1ce4+LXmQ0TBQfVibXAal2BDC5eENgO42fzKmRh4W63E6KNQyz2r9u/Inv/0Z+hXbHuNbfCnnvDBZ4dzxdjzxr1ZtAOjBpVILEeb3F1uXlhwDAC1334byBrHGufddjz9aduCslqA0Vmp4wex87kLOd8OnYBZu9fvwb6XYPIKyqhbGxc565XLQii774KREM5q4SyJo5h8oecE9lSLYIT9C8v1K529HNyUt399p9vLuPaJrAPLxl0t04IMJOWRq0et0Qi4unHxYXBDe0uvoDvE3Rw0UCgCzmtFFPo69lTLnCo/xnhbuaXTwObPhYQG7Vzqr1iaE0ig9dWOLhGMNYLWF6RkEhpENEsyxLIk+mA6YdlrwRIwsafyfQ8ulg4Ssipfl5XjHeXSkg+U2/7E5Jh7PTcKNWV0lLLSghw/8N3w01T+PNpUPKm5QXBZWN10hxngu74hZUxDK7HSef737S93gZhsJoRrnsoLOZdZSOCBkqRrVzfWN+8zqMMn1S6KIPS0fEQd4EWQ+nGctp/FiZPyPOYzw1lcqnq3Hz2aTarwBvzNeuvADv1Mi86g59s62TuQ3fLfcsR2ewHbfwuRT1yzsqe3HNiHx0mmxYx3NCd0fw/dBANlvBPjyNsPiUkNfyFoHARcR48zwlh67sax0twypAnqjpxmhwvq8lLtbYFFlog5D7UpYl/Cua4tS3CIEOz+I+yC+9kn8liPyJ5B+9Agj58Tl34As5hGCDlaUFFEHqUySl7pljQjtSnvhIw5oXS3CDCnLOST3F4IEWQRlBxlrnahG6r0PqnYu9ARBzXEl5zSPA2wCGvYgiQC8sQwowj1uB7hRSDXTBV1GX2tfFHgZe0lCkZBtSYlWKhyqAD8HVCbyriJA/xgrvlmsOOxf5 ygbPKBqh 0xphaPoGTKKxPr2yP1ZZtRP2tFOaap8X7geQal64H2wNhrMBKiCt09nMdoJFcMUcuEf7Ngl+30Jk7OFC7vCPHgc8EJCZdDHVM+Gmgzq1GeP9CUp66ZBK1ncPTDcS57ORAUPPGkwkhAirrHsk2FrC9h4eevd45ZUfguk2INmgY/b0uvQORs/CRxk7MdjdzlcIMLCDbcYsCKO7V7WUkojyW0VOyAHDFm1kZaAy0uot9X+J05FIUlmoQolmNiDjXO87c+mthWZWKKvbAHYnzO2dVJUB1Gw== 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: List-Subscribe: List-Unsubscribe: Gregory Price writes: > On Tue, Dec 12, 2023 at 03:08:24PM +0800, Huang, Ying wrote: >> Gregory Price writes: >> >> >> For example, can we use something as below? >> >> >> >> long set_mempolicy2(int mode, const unsigned long *nodemask, unsigned int *il_weights, >> >> unsigned long maxnode, unsigned long home_node, >> >> unsigned long flags); >> >> >> >> long mbind2(unsigned long start, unsigned long len, >> >> int mode, const unsigned long *nodemask, unsigned int *il_weights, >> >> unsigned long maxnode, unsigned long home_node, >> >> unsigned long flags); >> >> >> > >> > Your definition of mbind2 is impossible. >> > >> > Neither of these interfaces solve the extensibility issue. If a new >> > policy which requires a new format of data arrives, we can look forward >> > to set_mempolicy3 and mbind3. >> >> IIUC, we will not over-engineering too much. It's hard to predict the >> requirements in the future. >> > > Sure, but having the mempolicy struct at least gives us more flexibility > than the original interface. > >> >> A struct may be defined to hold mempolicy iteself. >> >> >> >> struct mpol { >> >> int mode; >> >> unsigned int home_node; >> >> const unsigned long *nodemask; >> >> unsigned int *il_weights; >> >> unsigned int maxnode; >> >> }; >> >> >> > >> > addr could be pulled out for get_mempolicy2, so i will do that >> > >> > 'addr_node' and 'policy_node' are warts that came from the original >> > get_mempolicy. Removing them increases the complexity of handling >> > arguments in the common get_mempolicy code. >> > >> > I could probably just drop support for retrieving the addr_node from >> > get_mempolicy2, since it's already possible with get_mempolicy. So I >> > will do that. >> >> If it's necessary, we can add another struct for get_mempolicy2(). But >> I don't think that it's necessary to add get_mempolicy2() specific >> parameters for set_mempolicy2() or mbind2(). > > After edits, the only parameter that doesn't have parity between > interfaces is `addr_node` and `policy_node`. This was an unfortunate > wart on the original get_mempolicy() that multiplexed the output of > (*mode) based on whether MPOL_F_NODE was set. > > Example: > if (MPOL_F_ADDR | MPOL_F_NODE), then get_mempolicy() would return > details about a VMA mempolicy + the node of that address in (*mode). > > Right now in get_mempolicy2() I fetch this unconditionally instead of > requiring MPOL_F_NODE. I did not want to multiplexing (*mode) output. > > I see two options: > 1) Get rid of MPOL_F_NODE functionality in get_mempolicy2() > If a user wants that information, they can still use get_mempolicy() > > 2) Keep MPOL_F_NODE and mpol_args->addr_node/policy_node, but don't allow > any future extensions that create this kind of situation. 3) Add another parameter to get_mempolicy2(), such as "unsigned long *value" to retrieve addr_node or policy_node. We can extend it to be a "struct *" in the future if necessary. > I'm fine with either. I originally aimed for get_mempolicy2() to be > all of get_mempolicy() features + new data, but that obviously isn't > required. -- Best Regards, Huang, Ying