From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="rY6nmgxx" Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 048C7C9; Tue, 5 Dec 2023 00:51:45 -0800 (PST) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7B79921F68; Tue, 5 Dec 2023 08:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1701766303; 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=iYZrHcRKmIrpOYrKMr35EBcUWS2p3IpXTZ63lUIPXII=; b=rY6nmgxxV/dp2Txfm9owLYj4Xm0chzSf5QtJ9SHZhSfsxUm8HpyKu2Di1fmddShakHu/lo lxUyRPsPuOy3Ws+nldU7ljrsKFaPZp5lJXD4Gcgt7QtfPX/R6i+PiZnRdf06YrsP8183/b LGHmH3HZswyx3flQnuYHj8AcLNNjH9Q= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 71D6B136CF; Tue, 5 Dec 2023 08:51:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id k77CG5/kbmXvQgAAD6G6ig (envelope-from ); Tue, 05 Dec 2023 08:51:43 +0000 Date: Tue, 5 Dec 2023 09:51:39 +0100 From: Michal Hocko To: Srinivasulu Thanneeru Cc: aneesh.kumar@linux.ibm.com, linux-cxl@vger.kernel.org, linux-mm@kvack.org, dan.j.williams@intel.com, hannes@cmpxchg.org, hasanalmaruf@fb.com, haowang3@fb.com, ying.huang@intel.com, gregory.price@memverge.com, tj@kernel.org, hezhongkun.hzk@bytedance.com, fvdl@google.com, john@jagalactic.com, emirakhur@micron.com, vtavarespetr@micron.com, Ravis.OpenSrc@micron.com, Jonathan.Cameron@huawei.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [EXT] Re: [RFC PATCH 0/2] Node migration between memory tiers Message-ID: References: <20231130220422.2033-1-sthanneeru.opensrc@micron.com> <1db561a9-6984-418d-9305-a2a5ece93696@micron.com> <2552828e-6865-4fa8-a9c4-8ed76dd85257@micron.com> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2552828e-6865-4fa8-a9c4-8ed76dd85257@micron.com> Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spamd-Result: default: False [-3.80 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; RCPT_COUNT_TWELVE(0.00)[20]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-3.00)[100.00%] X-Spam-Score: -3.80 On Tue 05-12-23 14:12:17, Srinivasulu Thanneeru wrote: > > > On 12/5/2023 2:05 PM, Michal Hocko wrote: > > CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message. > > > > > > On Tue 05-12-23 01:26:07, Srinivasulu Thanneeru wrote: > > > > > > > > > On 12/4/2023 9:13 PM, Michal Hocko wrote: > > > > CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you recognize the sender and were expecting this message. > > > > > > > > > > > > On Fri 01-12-23 03:34:20, sthanneeru.opensrc@micron.com wrote: > > > > > From: Srinivasulu Thanneeru > > > > > > > > > > The memory tiers feature allows nodes with similar memory types > > > > > or performance characteristics to be grouped together in a > > > > > memory tier. However, there is currently no provision for > > > > > moving a node from one tier to another on demand. > > > > > > > > Could you expand on why this is really needed/necessary? What is the > > > > actual usecase? > > > > > > Hi Michal Hock, > > > > > > Following two use-cases we have observed. > > > 1. It is not accurate to group similar memory types in the same tier, > > > because even similar memory types may have different speed grades. > > > > Presumably they are grouped based on a HW configuration. Does that mean > > that the configuration is wrong? Are you trying to workaround that by > > this interface? > > > > > 2. Some systems boots up with CXL devices and DRAM on the same memory-tier, > > > we need a way to move the CXL nodes to the correct tier from the user space. > > > > Again, could you expand a bit more and explain why this cannot be > > configured automatically? > > Yes, in both cases above, if hardware not automatically populated properly, > in that case this interface would help to correct it from user space. > > We had observed case-2 in our setups. How hard it is to address this at the HW level? Btw. this is really important piece of context that should be part of the changelog. Quite honestly introducing user interfaces solely to workaround HW issues seems a rather weak justification. Are there any usecases you can think of where this would be useful? -- Michal Hocko SUSE Labs