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 E7E4BC38A02 for ; Mon, 31 Oct 2022 09:18:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23C2F6B0071; Mon, 31 Oct 2022 05:18:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EC936B0073; Mon, 31 Oct 2022 05:18:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B4DE6B0074; Mon, 31 Oct 2022 05:18:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D53576B0071 for ; Mon, 31 Oct 2022 05:18:56 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 731B6C05A2 for ; Mon, 31 Oct 2022 09:18:56 +0000 (UTC) X-FDA: 80080695072.26.A3B4F59 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf25.hostedemail.com (Postfix) with ESMTP id 9A2B2A000C for ; Mon, 31 Oct 2022 09:18:55 +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 1FAA41F91D; Mon, 31 Oct 2022 09:18:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1667207934; 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=5f+L4lFYRpVQJbtga4qXT/E9MSZAjXCdeB1iVrLLAwE=; b=nuddbqq6TZ5pf7kcq2IG5RchiKUxQQg5buEf9Z/wa2aKMhbg7b3HUcgyRFp3A6JPC0e4Qc 7IwSXh9euPvo2ECab2gA2wkXzqpsEoE/cAkSKxkTiovPpHcG+WOi708agMeYmFKIJzN6EH P5RsnzkHClZu3MXCxPxAvl0nryGA4GE= 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 F31D213AAD; Mon, 31 Oct 2022 09:18:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id gYQdOf2SX2OMVwAAMHmgww (envelope-from ); Mon, 31 Oct 2022 09:18:53 +0000 Date: Mon, 31 Oct 2022 10:18:53 +0100 From: Michal Hocko To: "Huang, Ying" Cc: Feng Tang , Aneesh Kumar K V , Andrew Morton , Johannes Weiner , Tejun Heo , Zefan Li , Waiman Long , "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: <87wn8lkbk5.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o7txk963.fsf@yhuang6-desk2.ccr.corp.intel.com> <87fsf9k3yg.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkpwkg24.fsf@yhuang6-desk2.ccr.corp.intel.com> <87wn8gcr5s.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn8gcr5s.fsf@yhuang6-desk2.ccr.corp.intel.com> ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=nuddbqq6; spf=pass (imf25.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=1667207936; a=rsa-sha256; cv=none; b=Rm/Ua4DPfiMcFJ4S9bYbfBabbMawLuXDgjdB2e51LEp3A3tAAmCavlo03efEMG9OVJgh8M Qh74CYpTHwHoZHRHVDG2CtGuvFn0C0Z/fY9tBiPpQh5etuDdbZw7TYczbTn8ZbmPa7CVS3 n8jAWAZG7PzOx7rTHceiaWNvMtdkKSM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667207936; 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=5f+L4lFYRpVQJbtga4qXT/E9MSZAjXCdeB1iVrLLAwE=; b=D8hs+owXYrSqb4QQaAg/uwywiIhR9WbjzwkYwN0SB8PlYxU9NwJywgb2mVy2gbtVAFT2pL P8nUu1H6TtCpjXRGkr9QQEVBJjp+vaWR2mJK/W/tmNt5lumIyaajRO9ju92H8xkshE2tMZ NdasvtxP6TYeTjrpbKCLVT+UVNdEGII= X-Rspam-User: X-Rspamd-Queue-Id: 9A2B2A000C Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=nuddbqq6; spf=pass (imf25.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: 9by9pwyp5mrkxpn1t73m83dhmrf6iw3d X-Rspamd-Server: rspam10 X-HE-Tag: 1667207935-320346 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 31-10-22 16:51:11, Huang, Ying wrote: > Michal Hocko writes: > > > On Fri 28-10-22 07:22:27, Huang, Ying wrote: > >> Michal Hocko writes: > >> > >> > On Thu 27-10-22 17:31:35, Huang, Ying wrote: > > [...] > >> >> I think that it's possible for different processes have different > >> >> requirements. > >> >> > >> >> - Some processes don't care about where the memory is placed, prefer > >> >> local, then fall back to remote if no free space. > >> >> > >> >> - Some processes want to avoid cross-socket traffic, bind to nodes of > >> >> local socket. > >> >> > >> >> - Some processes want to avoid to use slow memory, bind to fast memory > >> >> node only. > >> > > >> > Yes, I do understand that. Do you have any specific examples in mind? > >> > [...] > >> > >> Sorry, I don't have specific examples. > > > > OK, then let's stop any complicated solution right here then. Let's > > start simple with a per-mm flag to disable demotion of an address > > space. > > I'm not a big fan of per-mm flag. Because we don't have users for that > too and it needs to add ABI too. OK, if there are no users for opt-out then let's jus document the current limitations and be done with it. > > Should there ever be a real demand for a more fine grained solution > > let's go further but I do not think we want a half baked solution > > without real usecases. > > I'm OK to ignore per-task (and missing per-process) memory policy > support for now. I am against such a half baked solution. -- Michal Hocko SUSE Labs