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 14DD1FA3742 for ; Mon, 31 Oct 2022 08:52:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 759C16B0071; Mon, 31 Oct 2022 04:52:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E2546B0073; Mon, 31 Oct 2022 04:52:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A9E16B0074; Mon, 31 Oct 2022 04:52:03 -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 314966B0071 for ; Mon, 31 Oct 2022 04:52:03 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CAE6D8066E for ; Mon, 31 Oct 2022 08:52:02 +0000 (UTC) X-FDA: 80080627284.13.BB6DD98 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf12.hostedemail.com (Postfix) with ESMTP id B088040009 for ; Mon, 31 Oct 2022 08:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667206321; x=1698742321; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=GJpd8Xm2kiIYix/9b/pSxjuZ+hynXQIIYAwXtN4bVMk=; b=j1P5stSmMlM2VhJrjwHQgXRRtOv8FYDonWqyEhRXNzAtRIrz5dGLERYK eOA33j0CfVHrKIra6Lw4CO+ObTtyRE/9R1yHvkYTRN5aRRrc+YXNkkex7 EeV2x+TYXFnB9YFjScZUHj/ozEulhfQJ/8EqcPDdV7wihSTbXzd5kcRlP aVbe6tvcfTpwVfyl47VjEuxgCoM5YKG2GUuy/0ufui14ZE/nwDXqWEBCS Wud+eq0Zujz3VYzE5h2hHavmwPLcV5XSCeeNTqC9Jc/lN300xRylmrQQJ tK0hZuXLuUdmt+XEgkjQQ6VHj+h969oTfg7bJoUBu/AuvoZrAf4WeQZ0Y Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10516"; a="289240665" X-IronPort-AV: E=Sophos;i="5.95,227,1661842800"; d="scan'208";a="289240665" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 01:52:00 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10516"; a="722741094" X-IronPort-AV: E=Sophos;i="5.95,227,1661842800"; d="scan'208";a="722741094" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 01:51:57 -0700 From: "Huang, Ying" To: Michal Hocko 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 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> Date: Mon, 31 Oct 2022 16:51:11 +0800 In-Reply-To: (Michal Hocko's message of "Mon, 31 Oct 2022 09:40:15 +0100") Message-ID: <87wn8gcr5s.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667206322; 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=vaFWOjTWquyOz/D3ylRsnJiy3BX6ecaN+Xv/rYT59dM=; b=xw8iWJZURoSpTyht7aEci3KwKFeiIxswE+kNe8/nTs/ebQk4l6vUAoE0wxMr5Ehofp/f2Z AWL6lOC3lIH2SIXGcjxutmLUWY/jD6gw1KZ6ZLLD8yblulB+vbc3OMXk4uW4E78FKR6jQr qXZylUBHWcJkdgLBWmjodCDZaDIFCt8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=j1P5stSm; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667206322; a=rsa-sha256; cv=none; b=17JVpgmt8ZOjq0S/wqCbfaAAiOL7pjmvkHDlw2ZaE6NoSlo0yUGYDMVjirR+UdS9643on7 P7sCRGCVOtMF8z7gsZFeotfWaHIsSQZThWmjNuAA2nFC8c65TiCz5oBEkIWFNytJwKU7mB KXzk7bJ3elAeZzVe2CH2L3fG+pzQwPw= X-Stat-Signature: spaqnssq48sze3ah74gak5tnj85bn3ie X-Rspamd-Queue-Id: B088040009 Authentication-Results: imf12.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=j1P5stSm; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1667206321-152899 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: 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. > 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. Best Regards, Huang, Ying