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 E35D3C433F5 for ; Tue, 11 Oct 2022 19:29:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3543C6B0071; Tue, 11 Oct 2022 15:29:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 303456B0073; Tue, 11 Oct 2022 15:29:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CA586B0074; Tue, 11 Oct 2022 15:29:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0BBCC6B0071 for ; Tue, 11 Oct 2022 15:29:13 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 89958C0E94 for ; Tue, 11 Oct 2022 19:29:12 +0000 (UTC) X-FDA: 80009656944.25.17C84FB Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf13.hostedemail.com (Postfix) with ESMTP id 9D6F420022 for ; Tue, 11 Oct 2022 19:29:10 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1197E1F889; Tue, 11 Oct 2022 19:29:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1665516549; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nEMUDkYRdfE4vY5mjXK1cb1A3J1MmMksjA+ax0To5uY=; b=DDbvC0NQr4SrpJ4gKZjfv1Ri2c5ylwKBQAvdqzYhtAGEl6S4BUR9V7YCc2JNaHMuke8yva XslR/rbpoZxGKLhSJJ716TTWzhjSVro49rieJx22SEd+uV+Dz9rq5jVrl1p15ls6BuVHoD tYD9YFVmz88Lhtejb5/pR7WGaHHqNSo= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 167F4139ED; Tue, 11 Oct 2022 19:29:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zgCVLgPERWNzSAAAMHmgww (envelope-from ); Tue, 11 Oct 2022 19:29:07 +0000 Date: Tue, 11 Oct 2022 21:29:05 +0200 From: Michal Hocko To: Frank van der Linden 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, wuyun.abel@bytedance.com Subject: Re: [RFC] mm: add new syscall pidfd_set_mempolicy() Message-ID: References: <20221010094842.4123037-1-hezhongkun.hzk@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665516550; a=rsa-sha256; cv=none; b=VnPmAnYS3ueXk8MMxvCPM9nsOvNtUGseAImd4oe0NgYY8G0bVsGmbD3WzkLqGDaxcwzmRD WNK2bk/PqKH/WjcnRfhqauWp9DbUKkmtUfoTKcM+iGe48z6v68j7nqOYmTTtpWInrZENMy DMOFlDrLZJtlddvlb7RmbVe5bkP73BQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=DDbvC0NQ; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665516550; 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=nEMUDkYRdfE4vY5mjXK1cb1A3J1MmMksjA+ax0To5uY=; b=ogBy2m02HDau7hdVK9ND1SX2AQG9A7kWXItc8evP9FCY2gW60rqtQ7c9e9ynty7VYuhy4Q PCeADYyRH59Wbp3D2A4HaaZ7XWJEtnDjU86+/rliQ1C+ggfCnAbjez+MV1OhkLUS/DyXDe vsymqxHQ0QbnkHUx6KofZk+lmcIW5zk= X-Stat-Signature: 14sxb9njypa4jh9wiybexa4ercgno9ht X-Rspamd-Queue-Id: 9D6F420022 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=DDbvC0NQ; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1665516550-650697 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: On Tue 11-10-22 10:22:23, Frank van der Linden wrote: > On Tue, Oct 11, 2022 at 8:00 AM Michal Hocko wrote: > > > > On Mon 10-10-22 09:22:13, Frank van der Linden wrote: > > > For consistency with process_madvise(), I would suggest calling it > > > process_set_mempolicy. > > > > This operation has per-thread rather than per-process semantic so I do > > not think your proposed naming is better. > > True. I suppose you could argue that it should have been > pidfd_madvise() then for consistency, but that ship has sailed. madvise commands have per mm semantic. It is set_mempolicy which is kinda special and it allows to have per task_struct semantic even when the actual allocation is in the same address space. To be honest I am not really sure why that is this way because threads aim to share memory so why should they have different memory policies? I suspect that the original thinking was that some portions that are private to the process want to have different affinities (e.g. stacks and dedicated per cpu heap arenas). E.g. worker pools which want to be per-cpu local with their own allocations but operate on shared data that requires different policies. > > > Other than that, this makes sense. To complete > > > the set, perhaps a process_mbind() should be added as well. What do > > > you think? > > > > Is there any real usecase for this interface? How is the caller supposed > > to make per-range decisions without a very involved coordination with > > the target process? > > The use case for a potential pidfd_mbind() is basically a combination > of what is described for in the process_madvise proposal ( > https://lore.kernel.org/lkml/20200901000633.1920247-1-minchan@kernel.org/ > ), and what this proposal describes: system management software acting > as an orchestrator that has a better overview of the system as a whole > (NUMA nodes, memory tiering), and has knowledge of the layout of the > processes involved. Well, per address range operation is a completely different beast I would say. External tool would need to a) understand what that range is used for (e.g. stack/heap ranges, mmaped shared files like libraries or private mappings) and b) by in sync with memory layout modifications done by applications (e.g. that an mmap has been issued to back malloc request). Quite a lot of understanding about the specific process. I would say that with that intimate knowledge it is quite better to be part of the process and do those changes from within of the process itself. -- Michal Hocko SUSE Labs