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 29957C46CD2 for ; Tue, 2 Jan 2024 04:11:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 977226B00A7; Mon, 1 Jan 2024 23:11:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 94F826B00AF; Mon, 1 Jan 2024 23:11:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EEB06B00A7; Mon, 1 Jan 2024 23:11:10 -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 6E5D56B0099 for ; Mon, 1 Jan 2024 23:11:10 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 41BCCC03FC for ; Tue, 2 Jan 2024 04:11:10 +0000 (UTC) X-FDA: 81633045900.13.CF7FDFA Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf03.hostedemail.com (Postfix) with ESMTP id 2A2AB2000D for ; Tue, 2 Jan 2024 04:11:06 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lqQtsj6S; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 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=1704168668; 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=c+LzeNDPwEy7yp1+hhzsuEKSZO0dVANtUSJ1t3j2ekA=; b=Jujpkdh0eZ+y1ZLAcxEQ+oG+MmxHWTQMJpp7gKlny29rGR3pgNK2lAkp2wruzDP+U11Kjm 0xwF8N/22oK4PIwcnsBYITL7a9dQOzo6fX1E8y2ir1tQ/uPNhzLgLMQLyVpL0oqMo7eYxl X/RGs2ob6CbDiIC1eWwKljTJHPzLL9E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704168668; a=rsa-sha256; cv=none; b=OMpFwhBI4iqyRm5TGvXSAokEB6wm2KBmmLh/MbPsLB6NFTp5dCS9l2WO9UqIhyXXIg2mOv tyzbpWFe5tb8GdvcEaHJ0XSapPzfJMnhVmNgRlFdesOduIWYI3V0/XlqUoB3gf+zj2woDp Fxtg7jJ1bN+AmE+C0wGoHcobQkQ4zpM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lqQtsj6S; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704168667; x=1735704667; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=F8KbSo88fSGtWCt8yc1dnbNMXI7re2ui4GVuvfw30bo=; b=lqQtsj6SQbSZtGuiH/sxMq8MdsE8qYp7i70pb9BuF3ltbXgGE7vzb4a/ hUapzJ3FTVmM1cABe2uATFHmmxNsG/Osfuk3uVupO+zIru2ESK6vh9POW njnGhCFbuubvAyP58h4v1w0rs8LvkFFgmk1mbFiIIjr8VxBkm662qHenD cMUzTdiZC22KfexFi1yWM+bog+Y5vG5SNPZrn2eburRsY39VRWdISOJME cTwPaxpnofyMNpdOgkX57H3PlZIPu8FCFdbndaAsIXswqDsDxTnhJh0iN UsLeJsq8ww5bvcQYnuDovSAyPm0FZLFqp25dceAhD/1ruaCQ3huSmIAFb Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10940"; a="381794269" X-IronPort-AV: E=Sophos;i="6.04,324,1695711600"; d="scan'208";a="381794269" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jan 2024 20:11:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,324,1695711600"; d="scan'208";a="27966578" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jan 2024 20:10:56 -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 v4 00/11] mempolicy2, mbind2, and weighted interleave In-Reply-To: (Gregory Price's message of "Tue, 26 Dec 2023 02:26:21 -0500") References: <20231218194631.21667-1-gregory.price@memverge.com> <87wmtanba2.fsf@yhuang6-desk2.ccr.corp.intel.com> <87zfy5libp.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 02 Jan 2024 12:08:57 +0800 Message-ID: <87plyke5ra.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: 2A2AB2000D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: moiwd98uws3kkctdki3ozabdioaxzd89 X-HE-Tag: 1704168666-726579 X-HE-Meta: U2FsdGVkX1+IbwjjL+/tkEAPZ9kG8UUFlH6BUk/wkkjzUtl+09ttgIuv1GanJzvRU/fFeI4lubXsgPmo8jHz34uc6+rfcYRbPmPNVW1ggvlXdndBYyx/6ybJtC1TAs8kKD6QTAnjDOGRjIhQWPyt+M/vsUVQXdxu5FAvXUrRE6XV4yRMLOphS922hZjGkApB9IQx6CZfhyRoI02xiC+9vOOEZg4XslCXTNhriAo3KIJNaDl4hgAn6RwjErhiGm58lOV5EZeqJcomG6C94YSuh/SEIC50G+oMLfpF2LwSssYwbFg3YVmbJOiV4N/gMdTLoN3r+MqqswCmAavm4uwxl6ef5j3hrm9BD9vAvhTmvSHr0sVZzfeTDIfbpV4dd1iqfVpYt8n/mx0myYau4CNYSkNZcc/4erNr1Br1IYCu3ue3RH9oIOsNW94IB909vXFQzPAu6K0DHDFKvqmvRV3aWu8EBdzg4ya7PVRTpR2DHjYrX1LmFqVJ7Rt8bXi69EZ1X0Lh86U7MptFfWLcbfUT34nvd9YeL9oCObocLt1xNfCdk+AS5hU9ZVpyJHrc1cCOKjhh8pktiEj5+0S7sPw8qsVEoC7biByykjBHVn7+wu2nee1lzPqglu76mZSfDFp03W+KcJV0Jeash2LBTsHgSrJCA525nS8L2eo38F8qlrjxRHPahGjedZ7PVsLa/M9kn6pqaIXdJrkpbNNlZiyXh56m5AaG5QhJd/VcualKeDfXk4Z2XCB3Pc8tcbaYnuxsBFUadR0HheOLFXaKqqyCloVoBqvBTcsS+Tu9B/u/3+eF0R7BqlE73EUMyj2+k02x2mEZxuDeYMNm6brlNwuu7imh6mfss75YKC3yGUSnHeMr+qBvoVRp3G9b/6JyZlUTNSSe5ic5AmWhbqOmsA5yS6cwXgyBb8ZY89oxh10lMjIESiHW6oTpzKGDM4AEeY3oLq/Eb1O6RC++XoClLyU Te6YbnHw jV/HCJgf7dNAbxS6Yp0PHFVvTSwSezGbqVVvuHDQSg+ef3vMO7LrezZ0eS8Ff6Mpd3X4/zzm+TLnYLA6XB96elYooIAHuSV9Rl1/caaEdYdCcjzu85IY0HZOd9hcxAhvoFvoK3YsVXV8mXGqS5lfTVBZ6maYR9IB4nxX1m7K2aKRIOWlw6NPQhJAoF1K20AYE4FSlkJvgvNdmm0AONNhlu4PQ/YoZGcTCxI9qtSYKVoKOVnw9DN9tDpXzFV4HgORW1tYz1khoR3nWSTOfQco1ovQgWA== 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 Wed, Dec 20, 2023 at 10:27:06AM +0800, Huang, Ying wrote: >> Gregory Price writes: >> >> > Assuming we remove policy_node altogether... do we still break up the >> > set/get interface into separate structures to avoid this in the future? >> >> I have no much experience at ABI definition. So, I want to get guidance >> from more experienced people on this. >> >> Is it good to implement all functionality of get_mempolicy() with >> get_mempolicy2(), so we can deprecate get_mempolicy() and remove it >> finally? So, users don't need to use 2 similar syscalls? >> >> And, IIUC, we will not get policy_node, addr_node, and policy config at >> the same time, is it better to use a union instead of struct in >> get_mempolicy2()? >> > > We discussed using flags to change the operation of mempolicy earlier > and it was expressed that multiplexing syscalls via flags is no longer > a preferred design because it increases complexity in the long term. In general, I agree with that. "ioctl" isn't the best pattern to define syscall. > The mems_allowed extension to get_mempolicy() is basically this kind of > multiplexing. So ultimately I think it better to simply remove that > functionality from get_mempolicy2(). > > Further: it's not even technically *part* of mempolicy, it's part of > cpusets, and is accessible via sysfs through some combination of > cpuset.mems and cpuset.mems.effective. > > So the mems_allowed part of get_mempolicy() has already been deprecated > in that way. Doesn't seem worth it to add it to mempolicy2. > > > The `policy_node` is more of a question as to whether it's even useful. > Right now it only applies to interleave policies... but it's also > insanely racey. The moment you pluck the next interleave target, it's > liable to change. I don't know how anyone would even use this. Both sounds reasonable for me. How about add this into the patch description? This will help anyone who want to know why the syscall is defined this way. > If we drop it, we can alway add it back in with an extension if someone > actually has a use-case for it and we decide to fully deprecate > get_mempolicy() (which seems unlikely, btw). I still think it's possible, after decades. > In either case, the extension I made allows get_mempolicy() to be used > to fetch policy_node via the original method, for new policies, so that > would cover it if anyone is actually using it. -- Best Regards, Huang, Ying