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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B89FBC6FD27 for ; Wed, 2 Nov 2022 00:40:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229846AbiKBAkl (ORCPT ); Tue, 1 Nov 2022 20:40:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229795AbiKBAkj (ORCPT ); Tue, 1 Nov 2022 20:40:39 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73CCF140E4 for ; Tue, 1 Nov 2022 17:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667349638; x=1698885638; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=fw+qL17DCZK+sk+sa8WqB43dA7mfh93h7iE5JgG3lx4=; b=lYtSUisAs979oBUsDpK60WJ5SOZOcsANw4WVY4B4g6VGU3zB00hiziHc Uy/znDop0ZTn451vL9r6Ih5WgGInsfZJRfq/wtr20WqgDrPhcR6EHhCLx vf5A3sQeozBv9okP407802STWHvSPhULoEP5hS8JjU3MBlRAb0d2aNcE4 OJsEtr7xxTUQpLENhqNBMikhke+Xb479KVYK7FrIkS+DHt2pIeqpHCX0F Gp6t/X9R4WCD/kER8261sRooWQt55NMB2m4SFb6FbNAp7xN65KoyCrckZ ErLmfP4DzSVeN2DG6JQDH4wSI8vVloZsqyBvH0/9Ohxwr+U/GGGxwd/PZ g==; X-IronPort-AV: E=McAfee;i="6500,9779,10518"; a="310380096" X-IronPort-AV: E=Sophos;i="5.95,232,1661842800"; d="scan'208";a="310380096" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2022 17:40:37 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10518"; a="879281950" X-IronPort-AV: E=Sophos;i="5.95,232,1661842800"; d="scan'208";a="879281950" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2022 17:40:33 -0700 From: "Huang, Ying" To: Michal Hocko Cc: Bharata B Rao , Aneesh Kumar K V , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Alistair Popple , Dan Williams , Dave Hansen , Davidlohr Bueso , Hesham Almatary , Jagdish Gediya , Johannes Weiner , Jonathan Cameron , 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> <87tu3oibyr.fsf@yhuang6-desk2.ccr.corp.intel.com> <07912a0d-eb91-a6ef-2b9d-74593805f29e@amd.com> <87leowepz6.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 02 Nov 2022 08:39:49 +0800 In-Reply-To: (Michal Hocko's message of "Tue, 1 Nov 2022 15:34:51 +0100") Message-ID: <878rkuchpm.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Hocko writes: > On Mon 31-10-22 09:33:49, Huang, Ying wrote: > [...] >> In the upstream implementation, 4 tiers are possible below DRAM. That's >> enough for now. But in the long run, it may be better to define more. >> 100 possible tiers below DRAM may be too extreme. > > I am just curious. Is any configurations with more than couple of tiers > even manageable? I mean applications have been struggling even with > regular NUMA systems for years and vast majority of them is largerly > NUMA unaware. How are they going to configure for a more complex system > when a) there is no resource access control so whatever you aim for > might not be available and b) in which situations there is going to be a > demand only for subset of tears (GPU memory?) ? Sorry for confusing. I think that there are only several (less than 10) tiers in a system in practice. Yes, here, I suggested to define 100 (10 in the later text) POSSIBLE tiers below DRAM. My intention isn't to manage a system with tens memory tiers. Instead, my intention is to avoid to put 2 memory types into one memory tier by accident via make the abstract distance range of each memory tier as small as possible. More possible memory tiers, smaller abstract distance range of each memory tier. Best Regards, Huang, Ying