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 5C058C3DA6E for ; Wed, 3 Jan 2024 06:10:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEA926B031F; Wed, 3 Jan 2024 01:10:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B9B3C6B0320; Wed, 3 Jan 2024 01:10:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A89A56B0321; Wed, 3 Jan 2024 01:10:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9967A6B031F for ; Wed, 3 Jan 2024 01:10:00 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 71861402CD for ; Wed, 3 Jan 2024 06:10:00 +0000 (UTC) X-FDA: 81636974160.17.77018A2 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf09.hostedemail.com (Postfix) with ESMTP id 58A1B14000B for ; Wed, 3 Jan 2024 06:09:58 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kxsQriPi; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704262198; 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=T09AGaB9RSYfQGWH/QB0rMQh1A52Vf6GX4/AfGljIqM=; b=JLSF4QyFGqAf9mZzmM15qfNITM48XdHKvA7DcPPtEr5HbG9q0Ucd4AUT6O/9VEHAx83Xj2 QTRGe4qszbmIpzdnAGYzWmPNlozMJpqpgZ6xGs3yOzhDanHr/I55vEKwSJvpudMpFppsP9 yUFeL7/gVaGaJZ4/EW5aQSxuuhBdx8w= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kxsQriPi; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704262198; a=rsa-sha256; cv=none; b=5ohG7Xx8JHHuXt0+oUwGsljLALArqcXpN9YRNlN8eh8ZWV8bCxEsuhfKz+kzQ6soLqjssc nNbtMNyHlav0XiLQhRz/YyCs0dh0Qkbe6EgjBayauC+Rix+1fxrjp1ig+Ro+WEk3gYnb4W RYwnOcunQboKg7rCbk13a1ukyjTCd9k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704262199; x=1735798199; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=SlVD6Rk0BkluSSjYPsszZ6WpuFk/Fh1OB487VtaCkVo=; b=kxsQriPioQ2jRpIhqRhh5rKKp1Z4t1APfSGsF8PO7GG+VT86/8UnIMBd ze3iedOFHNdSWJQIjfI7OxCtMCzcOExO47frOajXVA38GoMW/EAYxUOLY ZR0tOhWX2oEaqLOqDG1RrMf2LLKTWzyFCC5ZHJSb7jUK7xBZYgoY9HOng w3RgAUvYpY4f5wXu9b3eXq0ojoLqLvLqEf0o1tfedBtG3XM9TogntEV5r YnhvJfbmIMeZwxFlNWAxpuzzUOFlYj8xs+B+xhev86Lgspdd9Z65g2rEO lY/Q5cHqopMLwhcHP3f9q70jWJd3vEVKrKtppEJGO6Kvq0AidUBS3Dcu7 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="4044340" X-IronPort-AV: E=Sophos;i="6.04,327,1695711600"; d="scan'208";a="4044340" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2024 22:09:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="903334248" X-IronPort-AV: E=Sophos;i="6.04,327,1695711600"; d="scan'208";a="903334248" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2024 22:09:52 -0800 From: "Huang, Ying" To: Srinivasulu Thanneeru Cc: gregory.price , Srinivasulu Opensrc , "linux-cxl@vger.kernel.org" , "linux-mm@kvack.org" , "aneesh.kumar@linux.ibm.com" , "dan.j.williams@intel.com" , "mhocko@suse.com" , "tj@kernel.org" , "john@jagalactic.com" , Eishan Mirakhur , Vinicius Tavares Petrucci , Ravis OpenSrc , "Jonathan.Cameron@huawei.com" , "linux-kernel@vger.kernel.org" , "Johannes Weiner" , Wei Xu Subject: Re: [EXT] Re: [RFC PATCH v2 0/2] Node migration between memory tiers In-Reply-To: (Srinivasulu Thanneeru's message of "Wed, 3 Jan 2024 05:26:32 +0000") References: <20231213175329.594-1-sthanneeru.opensrc@micron.com> <87cyv8qcqk.fsf@yhuang6-desk2.ccr.corp.intel.com> <87fs00njft.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 03 Jan 2024 14:07:54 +0800 Message-ID: <87edezc5l1.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 58A1B14000B X-Stat-Signature: y1kjq9f9mn5q4fjtdrjidqjn6ortq7ox X-Rspam-User: X-HE-Tag: 1704262198-135275 X-HE-Meta: U2FsdGVkX1/jniLAXDIP7XBkGej4iQDjVqhLJMamLFM0nCVpIaBuxqb48rbx6cbMHPBiCHGFv/k7NZHu3YNJPSwObOD96hOF8m/cxo6sw4CFSa8qy1U7vNOhBvuICTOpQibImbfDoldpKtrtV6lICswOv1Ez1LS8bsp27p83ptdD7ojwMzqc3W2aYujhcmEptYdLeJbbKeC6M+5wsgpPJhjDKLmOUHh/KC6g8sjMczJT9UOQt0TOkqWVCrWbaX4CFpvnK931Ivc7XpTizcpg4XDRB7IzkiEBYTwN8eMd15mghy+1idGiV6GjLMiATJc/uqA8vzLeEWxKU61yN7wBIm0Y9R4y+d6GpQ+INBs0mxqUy59plKiR98XEfwJ8RUL5B5L1MCT+mHGh1sToQD3SjndNr/yE1PY48Mwh+w7nwb28SohU330kDTjJKT2gHNAOVN/FENButvdNtdYfpS3hXhuErByluPmOjLYbnaZ+XkW3k1bR7x+/wXDTzVrw/Dud7DAOV8UT2vXDGRIiS4ys0pQL7+VdYfd1f/1asoIfZaYTQlkR8z5pHTIEuGNnd+/2oYx1tY57GEDGXI4fCIq/scnVpptJ7ewqX9Kp7Xyh4Eaqsz23t5/0tEf9AxTspS7QA2okBwdRoDMzuTkK/E3sfUE9YY2RqWgXNM5ibVZ+L0/KrbOf26otRkLOGPILMn302ckQlqTUmqhsowVG+FnulnQy/Pwa62fbqzA3+q3shQI99o5oKETplSp9ZwFnjCUFS/093GKQojc/jMQ7v/7+bslCWi51KsGsxlP3/kyvdCJS1OM5ihIoTgk3XDzIZVV/UHt6s3HiLVExHFumMIS1/o5QSZgS5S9rQxcKfW6AFmkiI/NXHOa1aMMVCM5nkvq3F3EkuZy2cYD5lnCKtbs0zu9/W7D4QyjZrNZH/GMUvMQlj1Twwg6dx3utAyv7223ZBbYz4r1dlI2GcVHDqwL wMD6li07 9Y477rPlv2Rq4QU3EDJ+HZX02liuwPr3AhHyTJOPhBfdep1mThmCBWEa+QzAeYvD3cZvjkcJ3EFCORSb4oTsctB0gAaVdZksNInlC0cheB+LVRrToCcBpJxpIwtSUyKf8BlazZypEsWF/5eY31esb1q5QAYwHdsV2jjjqc4cZi69n9vSUOnvm4i5ha8+qDfgjzyzd7RBdB9oBVXRcw6/q1dnZ/WfL+Ia6w4Y5Dyayc0PwHZ8I0yXdj3izX1wPqTxfp3wKOZR8Qju1kHE7OQ8vi528tIVHn8VzXbht1LKoa6JFSaxmQzr9cuwK5lamKQVYVvDdQDq06Ba0DB838TiSqgXcUgZY/vP9guvW15/MFnk4YhG8kr2tT/gG9j9eMO1zvN9+wgdDf2XdGYyeLjRFpVkO4iC2XXNla7TKhKVG/p8nuXR2jbzw7eWiDVpVWLsdqWcYUrYmFCW3ScxU6iXf6QmOH/Qa+zHfEmqWgBee/ncqb8qzHDfC1chhF9HPBDVudSUcrt77q3uSkqEA5nKF5XiczPTtKGkXs82hBgnt+Vmn/R756ufYNSKtRm0kI+eFFeczz2XWCVH2qzseei2OTDV+C8exEWE+LgtmoTBs6K2oTJO6dCYUuERn/OkUD8rEEUUQLUbp+uLDrkgbk/DKo+8d1yScVKR6SgA/CBNaRqPFk5nhAJGRf+Uc++kZb7xashjE8wRpapS177ahObsXJVgA9DnEdQan321POLt11/AwL5wjeCKQGrpM8AnnK6aF7ZCOwfUUWlQE0ZKcC8iYkszd+gs2LRCnX3nIqRldYGLU1A+pdOiW+x8YZhs5+IpCj8b6Wf1Gja63/dXwzqNX75WUUw== 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: List-Subscribe: List-Unsubscribe: Srinivasulu Thanneeru writes: > Micron Confidential > > Hi Huang, Ying, > > My apologies for wrong mail reply format, my mail client settings got changed on my PC. > Please find comments bellow inline. > > Regards, > Srini > > > Micron Confidential >> -----Original Message----- >> From: Huang, Ying >> Sent: Monday, December 18, 2023 11:26 AM >> To: gregory.price >> Cc: Srinivasulu Opensrc ; linux- >> cxl@vger.kernel.org; linux-mm@kvack.org; Srinivasulu Thanneeru >> ; aneesh.kumar@linux.ibm.com; >> dan.j.williams@intel.com; mhocko@suse.com; tj@kernel.org; >> john@jagalactic.com; Eishan Mirakhur ; Vinicius >> Tavares Petrucci ; Ravis OpenSrc >> ; Jonathan.Cameron@huawei.com; linux- >> kernel@vger.kernel.org; Johannes Weiner ; Wei Xu >> >> Subject: [EXT] Re: [RFC PATCH v2 0/2] Node migration between memory tiers >> >> CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless >> you recognize the sender and were expecting this message. >> >> >> Gregory Price writes: >> >> > On Fri, Dec 15, 2023 at 01:02:59PM +0800, Huang, Ying wrote: >> >> writes: >> >> >> >> > ============= >> >> > Version Notes: >> >> > >> >> > V2 : Changed interface to memtier_override from adistance_offset. >> >> > memtier_override was recommended by >> >> > 1. John Groves >> >> > 2. Ravi Shankar >> >> > 3. Brice Goglin >> >> >> >> It appears that you ignored my comments for V1 as follows ... >> >> >> >> >> https://lore.k/ >> ernel.org%2Flkml%2F87o7f62vur.fsf%40yhuang6- >> desk2.ccr.corp.intel.com%2F&data=05%7C02%7Csthanneeru%40micron.com >> %7C5e614e5f028342b6b59c08dbff8e3e37%7Cf38a5ecd28134862b11bac1d56 >> 3c806f%7C0%7C0%7C638384758666895965%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >> D%7C3000%7C%7C%7C&sdata=OpMkYCar%2Fv8uHb7AvXbmaNltnXeTvcNUTi >> bLhwV12Fg%3D&reserved=0 > > Thank you, Huang, Ying for pointing to this. > https://lpc.events/event/16/contributions/1209/attachments/1042/1995/Live%20In%20a%20World%20With%20Multiple%20Memory%20Types.pdf > > In the presentation above, the adistance_offsets are per memtype. > We believe that adistance_offset per node is more suitable and flexible. > since we can change it per node. If we keep adistance_offset per memtype, > then we cannot change it for a specific node of a given memtype. > >> >> >> https://lore.k/ >> ernel.org%2Flkml%2F87jzpt2ft5.fsf%40yhuang6- >> desk2.ccr.corp.intel.com%2F&data=05%7C02%7Csthanneeru%40micron.com >> %7C5e614e5f028342b6b59c08dbff8e3e37%7Cf38a5ecd28134862b11bac1d56 >> 3c806f%7C0%7C0%7C638384758666895965%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >> D%7C3000%7C%7C%7C&sdata=O0%2B6T%2FgU0TicCEYBac%2FAyjOLwAeouh >> D%2BcMI%2BflOsI1M%3D&reserved=0 > > Yes, memory_type would be grouping the related memories together as single tier. > We should also have a flexibility to move nodes between tiers, to address the issues. > described in use cases above. We don't pursue absolute flexibility. We add necessary flexibility only. Why do you need this kind of flexibility? Can you provide some use cases where memory_type based "adistance_offset" doesn't work? -- Best Regards, Huang, Ying