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 A930DFA3740 for ; Thu, 27 Oct 2022 13:05:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7A848E0002; Thu, 27 Oct 2022 09:05:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E03A48E0001; Thu, 27 Oct 2022 09:05:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7D8E8E0002; Thu, 27 Oct 2022 09:05:28 -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 B77968E0001 for ; Thu, 27 Oct 2022 09:05:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4EA631409FD for ; Thu, 27 Oct 2022 13:05:28 +0000 (UTC) X-FDA: 80066750736.02.A3A9537 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 8B49F160003 for ; Thu, 27 Oct 2022 13:05:26 +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 25E1A1F8BD; Thu, 27 Oct 2022 13:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1666875925; 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=iLNO8fwHXhHPJ6MycKJ73w5HGMLMj9HlWspV0+LyiJY=; b=rDEM3ZnGroiojMFPrn3cjucEP3ymtmI5jrPZuAxvb5gEMPrn0HIj7PmXKMYgHo1+tO7yE2 6urCMiTAG71A2qFslg+sHC6po5k0B6snagoA3ro5K29S4RuzkKtq0qdXHCrGD7CohRaAAK dRp+4plLctbuWS/EqHucGbLmAfiWebU= 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 EFFFE134CA; Thu, 27 Oct 2022 13:05:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id D90POBSCWmNLXgAAMHmgww (envelope-from ); Thu, 27 Oct 2022 13:05:24 +0000 Date: Thu, 27 Oct 2022 15:05:23 +0200 From: Michal Hocko To: Aneesh Kumar K V Cc: Feng Tang , Andrew Morton , Johannes Weiner , Tejun Heo , Zefan Li , Waiman Long , "Huang, Ying" , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Hansen, Dave" , "Chen, Tim C" , "Yin, Fengwei" Subject: Re: [PATCH] mm/vmscan: respect cpuset policy during page demotion Message-ID: References: <44e485d4-acf5-865d-17fe-13be1c1b430b@linux.ibm.com> <22590f74-ec91-e673-32df-8a04b4ab3931@linux.ibm.com> <5a6c29f9-1154-03af-c22e-55108feb155f@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a6c29f9-1154-03af-c22e-55108feb155f@linux.ibm.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666875926; 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=iLNO8fwHXhHPJ6MycKJ73w5HGMLMj9HlWspV0+LyiJY=; b=DG1R0PpRMfl2x4M7ISvOT3eztyAleSDCuZZT9U3QHawkH3jzSF+9QlA0k/oNlt9aM4QbAe kbSMUptiBGDJyZ3F8paFo7K5kVUyzVAceYlo4VbUjPQfytdPKIKlsqSe8yx8DXg2WvNZne kVf23k4DhFiEcOEt87SgWVIxrTKQJLE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rDEM3ZnG; spf=pass (imf08.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666875926; a=rsa-sha256; cv=none; b=UCzqBsvBiMs4+SXwuEGDfxYOhob+q0BWnIeXnQp0a47J6pHWMWA1f/jnc9f3nPpUjjUS1H Q6dRtF9gp2MhO+GQ2S1Ft9yz71gqF/5foX8pgBUdY3L7yoTmpuwstHh7c8XNgnICwmhrrz pRpmb/NyK7RlBcYh2/ql/LQdW1H6XSA= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rDEM3ZnG; spf=pass (imf08.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-Stat-Signature: uuhs1t68bpmdse6qwqn7di3epxjcawsq X-Rspamd-Queue-Id: 8B49F160003 X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1666875926-940106 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 Thu 27-10-22 15:46:07, Aneesh Kumar K V wrote: > On 10/27/22 2:32 PM, Michal Hocko wrote: > > >> > >> Sorry, I meant MAP_ANONYMOUS | MAP_SHARED. > > > > I am still not sure where you are targeting to be honest. MAP_SHARED or > > MAP_PRIVATE both can have page shared between several vmas. > > > What I was checking was w.r.t demotion and shared pages do we need to > cross-check all the related memory policies? On the page fault side, we don't do that. Yes, because on the page fault we do have an originator and so we can apply some reasonable semantic. For the memory reclaim there is no such originator for a specific page. A completely unrelated context might be reclaiming a page with some mempolicy constrain and you do not have any records who has faulted it in. The fact that we have a memory policy also at the task level makes a completely consistent semantic rather hard if possible at all (e.g. what if different thread are simply bound to a different node because shared memory is prefaulted and local thread mappings will be always local). I do not think shared mappings are very much special in that regards. It is our mempolicy API that allows to specify a policy for vmas as well as tasks and the later makes the semantic for reclaim really awkward. -- Michal Hocko SUSE Labs