From: "Huang, Ying" <ying.huang@intel.com>
To: Gregory Price <gregory.price@memverge.com>
Cc: Gregory Price <gourry.memverge@gmail.com>, <linux-mm@kvack.org>,
<linux-doc@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-api@vger.kernel.org>,
<x86@kernel.org>, <akpm@linux-foundation.org>, <arnd@arndb.de>,
<tglx@linutronix.de>, <luto@kernel.org>, <mingo@redhat.com>,
<bp@alien8.de>, <dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<mhocko@kernel.org>, <tj@kernel.org>, <corbet@lwn.net>,
<rakie.kim@sk.com>, <hyeongtak.ji@sk.com>, <honggyu.kim@sk.com>,
<vtavarespetr@micron.com>, <peterz@infradead.org>,
<jgroves@micron.com>, <ravis.opensrc@micron.com>,
<sthanneeru@micron.com>, <emirakhur@micron.com>,
<Hasan.Maruf@amd.com>, <seungjun.ha@samsung.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Hasan Al Maruf <hasanalmaruf@fb.com>,
Hao Wang <haowang3@fb.com>,
Dan Williams <dan.j.williams@intel.com>,
"Michal Hocko" <mhocko@suse.com>,
Zhongkun He <hezhongkun.hzk@bytedance.com>,
"Frank van der Linden" <fvdl@google.com>,
John Groves <john@jagalactic.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v4 00/11] mempolicy2, mbind2, and weighted interleave
Date: Tue, 02 Jan 2024 12:08:57 +0800 [thread overview]
Message-ID: <87plyke5ra.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <ZYqAHesihJ+XCCyy@memverge.com> (Gregory Price's message of "Tue, 26 Dec 2023 02:26:21 -0500")
Gregory Price <gregory.price@memverge.com> writes:
> On Wed, Dec 20, 2023 at 10:27:06AM +0800, Huang, Ying wrote:
>> Gregory Price <gregory.price@memverge.com> 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
prev parent reply other threads:[~2024-01-02 4:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 19:46 [PATCH v4 00/11] mempolicy2, mbind2, and weighted interleave Gregory Price
2023-12-18 19:46 ` [PATCH v4 01/11] mm/mempolicy: implement the sysfs-based weighted_interleave interface Gregory Price
2023-12-18 19:46 ` [PATCH v4 02/11] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving Gregory Price
2023-12-18 19:46 ` [PATCH v4 03/11] mm/mempolicy: refactor sanitize_mpol_flags for reuse Gregory Price
2023-12-18 19:46 ` [PATCH v4 04/11] mm/mempolicy: create struct mempolicy_args for creating new mempolicies Gregory Price
2023-12-18 19:46 ` [PATCH v4 05/11] mm/mempolicy: refactor kernel_get_mempolicy for code re-use Gregory Price
2023-12-18 19:46 ` [PATCH v4 06/11] mm/mempolicy: allow home_node to be set by mpol_new Gregory Price
2023-12-18 19:46 ` [PATCH v4 07/11] mm/mempolicy: add userland mempolicy arg structure Gregory Price
2023-12-18 19:46 ` [PATCH v4 08/11] mm/mempolicy: add set_mempolicy2 syscall Gregory Price
2023-12-18 19:46 ` [PATCH v4 09/11] mm/mempolicy: add get_mempolicy2 syscall Gregory Price
2023-12-18 19:46 ` [PATCH v4 10/11] mm/mempolicy: add the mbind2 syscall Gregory Price
2023-12-19 12:24 ` kernel test robot
2023-12-20 0:48 ` kernel test robot
2023-12-18 19:46 ` [PATCH v4 11/11] mm/mempolicy: extend set_mempolicy2 and mbind2 to support weighted interleave Gregory Price
2023-12-19 3:07 ` Huang, Ying
2023-12-19 18:12 ` Gregory Price
2024-01-03 11:16 ` Dan Carpenter
2023-12-19 3:04 ` [PATCH v4 00/11] mempolicy2, mbind2, and " Huang, Ying
2023-12-19 18:09 ` Gregory Price
2023-12-20 2:27 ` Huang, Ying
2023-12-26 7:26 ` Gregory Price
2024-01-02 4:08 ` Huang, Ying [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87plyke5ra.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=Hasan.Maruf@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=emirakhur@micron.com \
--cc=fvdl@google.com \
--cc=gourry.memverge@gmail.com \
--cc=gregory.price@memverge.com \
--cc=hannes@cmpxchg.org \
--cc=haowang3@fb.com \
--cc=hasanalmaruf@fb.com \
--cc=hezhongkun.hzk@bytedance.com \
--cc=honggyu.kim@sk.com \
--cc=hpa@zytor.com \
--cc=hyeongtak.ji@sk.com \
--cc=jgroves@micron.com \
--cc=john@jagalactic.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rakie.kim@sk.com \
--cc=ravis.opensrc@micron.com \
--cc=seungjun.ha@samsung.com \
--cc=sthanneeru@micron.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vtavarespetr@micron.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).