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 071CCC4167B for ; Tue, 5 Dec 2023 08:51:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 982616B0081; Tue, 5 Dec 2023 03:51:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90B996B0082; Tue, 5 Dec 2023 03:51:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AABF6B0083; Tue, 5 Dec 2023 03:51:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6632B6B0081 for ; Tue, 5 Dec 2023 03:51:47 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 28A8B8023B for ; Tue, 5 Dec 2023 08:51:47 +0000 (UTC) X-FDA: 81532146654.08.2769619 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf29.hostedemail.com (Postfix) with ESMTP id 16B3612001E for ; Tue, 5 Dec 2023 08:51:44 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rY6nmgxx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701766305; 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=iYZrHcRKmIrpOYrKMr35EBcUWS2p3IpXTZ63lUIPXII=; b=XE2Frbd8HraZ5vvbLwe7zNibjDD4CbCLPtU0yvCnFEwjj+zV+SMXeQX+ue4MqJf3myOR80 8ZCldKoHCNjodLSYM4Rhjxyrg+OkzQnqUC/+LKQFX5foZ5OnzJK2i3yIKVLazLWkDcskWS 6mm6zxRTwAN36SW+JiE2D/h/KKBZNIU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rY6nmgxx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701766305; a=rsa-sha256; cv=none; b=bxTfDfP4AABQDAJ/HzB1xKbdRv+a2a+Ipk/4EC/tdFaKXwZ0PcEF8saEP+0pMQFdlVjXLk WMcxVo6rYKsOWbcoMFDgr5+Qd6TMzJwXfvX0cxm4ZNc6aKuLQMre9rIdbCVEm9W8qlqXWV Qge1+zSr7Pn4FVJuevXQHHctVggn9NA= 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2552828e-6865-4fa8-a9c4-8ed76dd85257@micron.com> X-Rspamd-Queue-Id: 16B3612001E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: sw66pg3f4re1sq4rctdfpknrqwtenmqm X-HE-Tag: 1701766304-274975 X-HE-Meta: U2FsdGVkX1+eF1mgOKFwOi1AuIaUScRXe2NaiWfgivOox0GZ1sF+jIi4afXmGZYq6w7rDZnDB7AAGZ5DXK+zEnWZP6hOL4JryAmjfArTPbiGchPbE3F+Y6Pt2F7hVRUX6l5u7PDiy+0YszIbK8XdIP11wIaUee81ksA5Glf6RTDZVxiiETZH7VM9jRfCS5j9Gy7zIWgRD5bTsy11CBl/v46tot+zm/UVyklNdWxVQjmomDm7R5+EIw3eru0jSDeP6CrXdMvlIJ6+QWWTiwSH7aUlrWUJ31nIO6KaGAhkZZRwhMexU7kPSH2oMDj7gBiFPs1X+WoRXXnHoTpkPYBdsL9mh8Pxb94oP4uh8W6NkuDGNkthm5TQ4A37K79Po9xlJ7/LmxmN4WW7nt6QfWrjxkzvs9Q1ps0SFea0vhpSWAeFKvfyydGTjVjWArsI49znBxhlotB++cBv3KNJjJeGgQSgAJ95CRFa7qcEh0aEuos1bPZrOO2+y8qkvE4LCdEA1c836QxU7eApGm5IgDRJ/9oH84aquMjj5TiT5btBCiSOZuTQcY3JjUAN2YFQGinOQsJzaqN35MrHPcNi+jen/f3dtzAH1Lp7agcmAJr5E7nuZRwffJvy8YM7F8Pvd4oaxzOsO3/kDdOfmSKjhd1D3zX2R9rI2LdMxB/sO1iSoodcCXPgt515bzyDIkNpSfvvHlAOCgMR04tOEQNYedo9cuMNmIxBmiVOgdqApJHo2GMCEXgUloNcDsKmh7VXPtAd+6gV+5CxKCTAO0jFPmkJdXVLdh2NAD9PAEBNZ0FDSDSKw1pddNONfD/pu0yEv0JYCzrEtbwuSAxjvELT/2ZjQYcfbjEXdekxf+tAPBkpJs82VbIKN7VcasJNQNhuhB6C6pWxsER9fimB/CDtnuO65rBerlX0rTr04EsUSmcWGu/fbri4PejRb2dWZMJSm0GU18j1jv3xI7I12q98/VE O/zJ/kRf PmGfP5tBmhyBttYZmYCbZOu98tsTU6IXAb01zELO2LKmcJE6R5UdmoP33998OrrYPF7978lIXNCRA2aIPd+q0hZDnvJWYc0OcQ2z175gj1PbVrKgbwztQ5o97Q72SWB5ieAaKNlaF4LpvD2SG08HjcMrxbZmcfMKk+UoXvJbIUGZRj6Ec6q59024IFkT+a1UeGwA2TZJ4KUKhCGnUeykSCmLWim1f6WjBbP5UsskHA+VRn7gnm2sU7jNinMWZh7ZMbw/aew+zRu9LVShoOaT0PMsS3g== 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: 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