Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Date:   Mon, 27 Nov 2023 11:14:44 -0500
From:   Gregory Price <gregory.price@memverge.com>
To:     Michal Hocko <mhocko@suse.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Gregory Price <gourry.memverge@gmail.com>, linux-mm@kvack.org,
        linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-kernel@vger.kernel.org, arnd@arndb.de, tglx@linutronix.de,
        luto@kernel.org, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        tj@kernel.org, ying.huang@intel.com
Subject: Re: [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally
 modifiable via syscall and procfs
Message-ID: <ZWTAdKnBVO0+5bbR@memverge.com>
References: <20231122211200.31620-1-gregory.price@memverge.com>
 <20231122133348.d27c09a90bce755dc1c0f251@linux-foundation.org>
 <ZV5/ilfUoqC2PW0D@memverge.com>
 <ZWS19JFHm_LFSsFd@tiehlicka>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZWS19JFHm_LFSsFd@tiehlicka>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9gI5u5UaE+LGl1pKWYmuVOx0Ppzy9Kf0xMqJk/wODCjJ25bngK7y4aEx5uWT?=
 =?us-ascii?Q?bsQshGTLqnNVg2UX9Zq95qHvP5aV2aK2YaYsEiRG+5tlEKmeACkf/38wvUt3?=
 =?us-ascii?Q?lTOUl9j1X/TzgO+Rh1s5/NrXyaeLDL+z3JZJiuVl8rpVKaBUl+4vWX03b2Zb?=
 =?us-ascii?Q?btiJDb3V5zWPMsZkjDii7OOSQoSUUMSseaWj4YUuaGTOQer3REQvUrZ+Syaq?=
 =?us-ascii?Q?gQ+36nCKaWLHnnf+WaQvKqswyxxzJUr3w8jmHD5GnULVYGn49NHttYyYxCcD?=
 =?us-ascii?Q?+COLAaV5OaNh14coREDz1MQrhdHcpkw1+FKGM69I7HAy6C29ZnlStO0FvwV5?=
 =?us-ascii?Q?AaH/1azxyEmsvqWnH34h7hhg7THGRVpFcIjq2s2rytLZvsM3Ni34JQO492T2?=
 =?us-ascii?Q?MupfxMTW0ACLZRsB47YMWD+sQkFjlCdE/rac6N4K5TFN6dsp8bdjM6mS/bKW?=
 =?us-ascii?Q?9QBhgnbX+YRyKdurgHipQ3+8LFYwu5WcBLeRvPJfHfiYP6gBrhxJfv2htmEX?=
 =?us-ascii?Q?nz2Ltq+NNHf/8cCYoJPvqkESSZpRk+ZBhIUs1gaHEzQ45NIipbpYcHUPzsG0?=
 =?us-ascii?Q?nTS4z1sy0ZG+adGrdigl3ErbJbV9lfkC8tZI0u7V2FEQLZmM8mz3g+ai5DQO?=
 =?us-ascii?Q?Mai2DlQXO0MW8cT1wx4EiSC42/XH/FE5Hfua7l+X1is/L4GAGbHRh1sXiZhH?=
 =?us-ascii?Q?9nnvdTUkt7sGKPmgi9ma193hZnV2aD+rUhU8idLLpFMn81hvBYpQZXabc3V4?=
 =?us-ascii?Q?P9l2nEr4IMJKb7M6vPAOtcVADNlUFWpeETo/laWtyzoRcUuFSP7Eck4JkTNr?=
 =?us-ascii?Q?zXTBzZeohNW8tGR/kZMcwjk5vdGhsOLhQS2JGOez+41cDNaoKPabnxUhC6uL?=
 =?us-ascii?Q?f9+yuGEmeLEUvcsu2zIIDBkjnLGWRo/t4dLSTyzaFYScOwm3QJiNHAZDD6Fm?=
 =?us-ascii?Q?rG4Uj5QvIuhysekBrUTTh8L9kxxO+0praaj97j1yBKMC/UkjikujTDl1L99R?=
 =?us-ascii?Q?yfG24+O6nMHo9fxnA5ZrprI7CrfA4UbM+/NUPU6pOM4p80dnwtToH1JyJvnZ?=
 =?us-ascii?Q?gs/1uOIWRW74dYX+lQszGG/DHKT64eFjSj7xP6E9eZPLwsUj6FlkjZd2vrTP?=
 =?us-ascii?Q?gnUpZse8uHSonlzmfIYp/IM1TR3M6keTw1joVGjW6WJiDVBDemUkI7luHRmx?=
 =?us-ascii?Q?GlYlR2dgOEKURiKjXKzTrX7IHpzKvsmVe6DOj7mL12t0+S/yflNw2wbe4ayR?=
 =?us-ascii?Q?LxGfq2LJF1KjDhM0hgKhEdOI3BaIA7RamK88qlzdTw70dCOAHd80h+aIB1wQ?=
 =?us-ascii?Q?qfSqvCG+YzgU7r2rZCnlpTV3Qtd/VIkQxnSKg8yzw5TUdmSeZVA4t7bjm0Qw?=
 =?us-ascii?Q?nFUzQtcGNR3lut7WDrS2IRp+5LUWxYcrvX2aUavoj4+PO/Z9bLOqBL4VmOAh?=
 =?us-ascii?Q?4PRGRk/GspeGwvURAPiYrcrW3otGRso7u/5di3ukpM1LPI8+a1oF3/FjabfX?=
 =?us-ascii?Q?BHHYdcE8VE0sVXTHu37OkKao4Wi8zF7h4pGNKi4KPD9bIP70jlvZHpNfGz/a?=
 =?us-ascii?Q?mhjcZAEDG7pUQ4yRk9pCFB3Yx3UyQ4S3oA2MINGPz0vmkT6raTwpxjpbgKO5?=
 =?us-ascii?Q?3A=3D=3D?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f5061f7-f429-4a1f-5661-08dbef640102
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2023 16:15:00.2107
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ChMJJSg0PJsS3DAKA22nMf8nmlg7MiEnWkm4s5pZ7tDEN4wE9yLeB3LUT4u+p9jdv1jtDa3ISpxHUZae18WKSK3By/xgIdtYeIClLTGaaYI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR17MB4837
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 27 Nov 2023 08:15:25 -0800 (PST)

On Mon, Nov 27, 2023 at 04:29:56PM +0100, Michal Hocko wrote:
> Sorry, didn't have much time to do a proper review. Couple of points
> here at least.
> 
> > 
> > So... yeah... the is one area I think the community very much needs to
> > comment:  set/get_mempolicy2, many new mempolicy syscalls, procfs? All
> > of the above?
> 
> I think we should actively avoid using proc interface. The most
> reasonable way would be to add get_mempolicy2 interface that would allow
> extensions and then create a pidfd counterpart to allow acting on a
> remote task. The latter would require some changes to make mempolicy
> code less current oriented.

Sounds good, I'll pull my get/set_mempolicy2 RFC on top of this.

Just context: patches 1-6 refactor mempolicy to allow remote task
twiddling (fixing the current-oriented issues), and patch 7 adds the pidfd
interfaces you describe above.


Couple Questions

1) Should we consider simply adding a pidfd arg to set/get_mempolicy2,
   where if (pidfd == 0), then it operates on current, otherwise it
   operates on the target task?  That would mitigate the need for what
   amounts to the exact same interface.

2) Should we combine all the existing operations into set_mempolicy2 and
   add an operation arg.

   set_mempolicy2(pidfd, arg_struct, len)

   struct {
     int pidfd; /* optional */
     int operation; /* describe which op_args to use */
     union {
       struct {
       } set_mempolicy;
       struct {
       } set_vma_home_node;
       struct {
       } mbind;
       ...
     } op_args;
   } args;

   capturing:
     sys_set_mempolicy
     sys_set_mempolicy_home_node
     sys_mbind

   or should we just make a separate interface for mbind/home_node to
   limit complexity of the single syscall?

Personally I like the dispatch for the extensibility nature of the arg
struct, but I can understand wanting to limit complexity of a syscall
interface for a variety of reasons.

~Gregory