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 032A4C38A02 for ; Fri, 28 Oct 2022 08:34:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B4836B0072; Fri, 28 Oct 2022 04:34:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33DA86B0073; Fri, 28 Oct 2022 04:34:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B69F6B0074; Fri, 28 Oct 2022 04:34:44 -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 08CE06B0072 for ; Fri, 28 Oct 2022 04:34:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B9953C0307 for ; Fri, 28 Oct 2022 08:34:43 +0000 (UTC) X-FDA: 80069697246.28.D3060BB Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf29.hostedemail.com (Postfix) with ESMTP id A0045120008 for ; Fri, 28 Oct 2022 08:34:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666946082; x=1698482082; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=I7+l1li97AG1W4nCdyskwIa37THe0xzjljy5/l3afeQ=; b=KQRhi/nIPXbyx53oWRDRqu2cA9MhLAeG0TQrztfQ6uyb6ItQ1zSs/lLC 4YI/UkxHBHGuM2VXpxE1h7uqs6oPKNpCBYBDb24T3j6TejBUnsEAnAXR4 2ZCGmOShB3ZZfcljjPTW/+hNPlRb7lBrn5s7FToQErET+iaO1S7H5ELe3 OvMvgYtTmXwo3uOlXFErMDJYuHv6QerA76VOL7nj1KZP+3k/FAD15IPCD GG21PPh5yIiMiqO2YknRAzZMG1Hekl1bpS8AeVR+8RK7Azh1SB0sh0Pcl 7erpAHPqcebpFmiCkvmYt5jrLOoeQGJCPv1QMsMejY2carzpYhe2U2lkH Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10513"; a="394756520" X-IronPort-AV: E=Sophos;i="5.95,220,1661842800"; d="scan'208";a="394756520" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2022 01:34:41 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10513"; a="632708139" X-IronPort-AV: E=Sophos;i="5.95,220,1661842800"; d="scan'208";a="632708139" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2022 01:34:37 -0700 From: "Huang, Ying" To: Bharata B Rao Cc: Aneesh Kumar K V , , , Andrew Morton , Alistair Popple , "Dan Williams" , Dave Hansen , Davidlohr Bueso , Hesham Almatary , Jagdish Gediya , Johannes Weiner , Jonathan Cameron , Michal Hocko , Tim Chen , Wei Xu , Yang Shi Subject: Re: [RFC] memory tiering: use small chunk size and more tiers References: <20221027065925.476955-1-ying.huang@intel.com> <578c9b89-10eb-1e23-8868-cdd6685d8d4e@linux.ibm.com> <877d0kk5uf.fsf@yhuang6-desk2.ccr.corp.intel.com> <59291b98-6907-0acf-df11-6d87681027cc@linux.ibm.com> <8735b8jy9k.fsf@yhuang6-desk2.ccr.corp.intel.com> <0d938c9f-c810-b10a-e489-c2b312475c52@amd.com> Date: Fri, 28 Oct 2022 16:33:48 +0800 In-Reply-To: <0d938c9f-c810-b10a-e489-c2b312475c52@amd.com> (Bharata B. Rao's message of "Fri, 28 Oct 2022 13:34:46 +0530") Message-ID: <87tu3oibyr.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-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="KQRhi/nI"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666946083; a=rsa-sha256; cv=none; b=xs3eT6LnJ1997AfbrCtcR/cwpmIqPmEsP+4/Ib5IBo1+8dRgakFw3hY1qdroet72lX9iSs DAtmWS2/VzePwf/IIvW/2hjKhKJkBuO3OOBXbJsLyqFT7HF8SUIkQ3TwIXvMRwtuZMu6eO 5IShQbxQwMtHIRL7Nry758AEnwqYO48= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666946083; 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=QKrBbY/bW6eKL14DjqWx1J+MBCbzq9RxDmsO4zfWh5o=; b=qGrHxxpjlimcDw4GMjC09XxvsAOq/YU2xU4aj+kDlYHri6J6KNFKttYben3dcxs53uIT42 nkIgD1v7IEaWAd93w8ZEPk7sgIjEQepiW3/kZYdmBgsiV5S9C4+XHddCV87w93tC0oTFlP VEKamtuUmhFRLl+PWAmpNci5pnVJAeY= Authentication-Results: imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="KQRhi/nI"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Stat-Signature: pa1i1nph6myq7863uyf1gdtyew1zyo9a X-Rspamd-Queue-Id: A0045120008 X-Rspamd-Server: rspam11 X-HE-Tag: 1666946082-884436 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: Bharata B Rao writes: > On 10/28/2022 11:16 AM, Huang, Ying wrote: >> If my understanding were correct, you think the latency / bandwidth of >> these NUMA nodes will near each other, but may be different. >> >> Even if the latency / bandwidth of these NUMA nodes isn't exactly same, >> we should deal with that in memory types instead of memory tiers. >> There's only one abstract distance for each memory type. >> >> So, I still believe we will not have many memory tiers with my proposal. >> >> I don't care too much about the exact number, but want to discuss some >> general design choice, >> >> a) Avoid to group multiple memory types into one memory tier by default >> at most times. > > Do you expect the abstract distances of two different types to be > close enough in real life (like you showed in your example with > CXL - 5000 and PMEM - 5100) that they will get assigned into same tier > most times? > > Are you foreseeing that abstract distance that get mapped by sources > like HMAT would run into this issue? Only if we set abstract distance chunk size large. So, I think that it's better to set chunk size as small as possible to avoid potential issue. What is the downside to set the chunk size small? Best Regards, Huang, Ying