Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp2443238rwi; Tue, 1 Nov 2022 07:47:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4BBsNiMgdERLvgLJgmpoP7WMOBHYi8OEF/NvyPBa1l0/NA3fvhcSCl3PGpt3qH/usBD8Td X-Received: by 2002:a17:903:41c5:b0:186:ceff:f805 with SMTP id u5-20020a17090341c500b00186cefff805mr20063516ple.31.1667314020812; Tue, 01 Nov 2022 07:47:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667314020; cv=none; d=google.com; s=arc-20160816; b=P1ZUuLvBa4/KpHvXA8qiczhAn8ro6BHNK3HrFcUK/f/cefbdjQJIqGnWY0meChYtxx tfcsSd8/7pZ9SOaueDpdorhDn8qTw8/JAfUNb+BVxds/mZWcVd7IsIyKVRTTgvLNXG7w vTSrJY7C7ta4cFG/hoQO5Ig3FZ+tzGZ16ap9sWK9tloEVLhnoHqC/TRMX+FwGf4H0L/Y z/ZtqqffdtP9RwIh/c/Y5D7YmNTSU0mfz7Oh4WATs4bL+fyz6xGgnn+JDTzEPM1q60KF F6B4eSvv30RpO8wZcjqIG1hTn4RLwo1/0aJ/MKf+KfBRIQm9JlFP30AMygzkVdEF2007 esow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=md7UdvagT3X4V8u77OX2NjG4n87gQfkAxPbnmYefNuc=; b=IMsf0Y3zDxuvyhDoL3SbM3jVmeWB9W33S4Ds0z+bjEm8uBEDDt//du86LGJzFBG94a gWEZg1a4TE3S6yHxSEqyrOWbHJ9UZ+bZkvWyozdLrqrESD2EkhkHUXISsI7ecWu8GOdU KDQUQit8OzwClbdevBPMEqZ0ggx9smah1mHNZnNHc+dMr0Og9ly0BNXq0mVTK1T/Cbk3 9Frv08bxcXSQhGTH+QmrxczlQ/XkZjBYYnOJjVjCHD4DFn8YSoyy3+BHsCOLyo8BKtIr czBbyiDWN6Kw2i/RxXVD6Fy73hd01lRY0qcrKBls8s62NdaY+VNlkT+9x6gVx+LjZGZU 3DCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=ZFyHqoxe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 22-20020a631856000000b00438b79bcf26si12941787pgy.151.2022.11.01.07.46.44; Tue, 01 Nov 2022 07:47:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=ZFyHqoxe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230339AbiKAOfI (ORCPT + 97 others); Tue, 1 Nov 2022 10:35:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbiKAOez (ORCPT ); Tue, 1 Nov 2022 10:34:55 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70F1F1BE8F for ; Tue, 1 Nov 2022 07:34:53 -0700 (PDT) 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-out1.suse.de (Postfix) with ESMTPS id 1F727336F9; Tue, 1 Nov 2022 14:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1667313292; 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=md7UdvagT3X4V8u77OX2NjG4n87gQfkAxPbnmYefNuc=; b=ZFyHqoxeRhYtLuEfJJNaBqeFdVHfTDO5Nw6gJoMHmH7yKnkMiUXJUeYsGswDVHeja9lhMH cixX1+RaowWVAo9iTCEgoLGomWiO4zrBnXZlIsAInL8LqcOmjtZeRrN2OWoBtE0ixgVwPc Qs18LUCGxWBtXDgWEZYyvQkLStW2lYU= 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 CF91F13AAF; Tue, 1 Nov 2022 14:34:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TWBUMIsuYWPeRgAAMHmgww (envelope-from ); Tue, 01 Nov 2022 14:34:51 +0000 Date: Tue, 1 Nov 2022 15:34:51 +0100 From: Michal Hocko To: "Huang, Ying" 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 Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87leowepz6.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?) ? Thanks! -- Michal Hocko SUSE Labs