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 C7B77C433FE for ; Mon, 14 Nov 2022 18:12:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 604098E0001; Mon, 14 Nov 2022 13:12:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B4256B007B; Mon, 14 Nov 2022 13:12:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47C058E0001; Mon, 14 Nov 2022 13:12:41 -0500 (EST) 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 37CE46B0074 for ; Mon, 14 Nov 2022 13:12:41 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B07F680B85 for ; Mon, 14 Nov 2022 18:12:40 +0000 (UTC) X-FDA: 80132843280.16.AC27A95 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf02.hostedemail.com (Postfix) with ESMTP id 0944D80014 for ; Mon, 14 Nov 2022 18:12:39 +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 A604420218; Mon, 14 Nov 2022 18:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1668449558; 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=KVwKZGg3oMnijACqeL9ZqfKWMlak+iItXqazHisGzUI=; b=KwaGqHwZvP04jjBZ2aWenp9eV3RLzfnOBEyFCAKEexdk7lWNJLfJFxxJx4z0JsEeE1Nco+ Ju6uiiftFCj8lEfY0d7dV45eZc7xcRTE735TdnINBD4Y0H8pIVqRcWgtUC4GpUFHKifhZ+ OCjMRFMiaA/AykO14G7IXAPhw91uiRM= 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 83A4113A8C; Mon, 14 Nov 2022 18:12:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id FmRBHRaFcmPdcAAAMHmgww (envelope-from ); Mon, 14 Nov 2022 18:12:38 +0000 Date: Mon, 14 Nov 2022 19:12:37 +0100 From: Michal Hocko To: Zhongkun He Cc: Andrew Morton , corbet@lwn.net, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [External] Re: [PATCH v2] mm: add new syscall pidfd_set_mempolicy(). Message-ID: References: <20221111084051.2121029-1-hezhongkun.hzk@bytedance.com> <20221111112732.30e1696bcd0d5b711c188a9a@linux-foundation.org> <3a3b4f5b-14d1-27d8-7727-cf23da90988f@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a3b4f5b-14d1-27d8-7727-cf23da90988f@bytedance.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668449560; a=rsa-sha256; cv=none; b=fMNI9wJnohZV2GjkuVqDig9OcOT3h3iawaQWJQPhSCqanezlr2W9uEMp85NyRZ+0ZnoqOC JJo7JlIZsjgmDZkMbWy3WliHuV6p4YSSFTdc/sWXNB0IFec1sVBOy243/7FgpuQm0feToW Gn9QP2jUnjgK/2kjsiCUr/3qbGAv1k0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KwaGqHwZ; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668449560; 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=KVwKZGg3oMnijACqeL9ZqfKWMlak+iItXqazHisGzUI=; b=E150yCqBMB+ref/hi+vrAfhcMaD9oGhXIeIhCo6ugx3at6b9xyof4MhcAd3SsSmoHKV7Mk mxGJE9HZyYMnQz+LZEhn41fJSwTtl1kYrykK7oH3+JdckPCVTyJVZgURaQyYkZOiHZRGRf R8O7JiM6hQyHUAIpFh89Sax1lzTxD88= X-Stat-Signature: rboegoabgetdirax53gdhowrpnad6kxa X-Rspamd-Queue-Id: 0944D80014 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KwaGqHwZ; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668449559-154836 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 Mon 14-11-22 23:12:00, Zhongkun He wrote: > Sorry,michal. I dont know if my expression is accurate. > > > > We shouldn't really rely on mmap_sem for this IMO. > > Yes, We should rely on mmap_sem for vma->vm_policy,but not for > process context policy(task->mempolicy). But the caller has no way to know which kind of policy is returned so the locking cannot be conditional on the policy type. > > There is alloc_lock > > (aka task lock) that makes sure the policy is stable so that caller can > > atomically take a reference and hold on the policy. And we do not do > > that consistently and this should be fixed. > > I saw some explanations in the doc("numa_memory_policy.rst") and > comments(mempolcy.h) why not use locks and reference in page > allocation: > > In process context there is no locking because only the process accesses > its own state. > > During run-time "usage" of the policy, we attempt to minimize atomic > operations on the reference count, as this can lead to cache lines > bouncing between cpus and NUMA nodes. Yes this is all understood but the level of the overhead is not really clear. So the question is whether this will induce a visible overhead. Because from the maintainability point of view it is much less costly to have a clear life time model. Right now we have a mix of reference counting and per-task requirements which is rather subtle and easy to get wrong. In an ideal world we would have get_vma_policy always returning a reference counted policy or NULL. If we really need to optimize for cache line bouncing we can go with per cpu reference counters (something that was not available at the time the mempolicy code has been introduced). So I am not saying that the task_work based solution is not possible I just think that this looks like a good opportunity to get from the existing subtle model. -- Michal Hocko SUSE Labs