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 091AEC4706C for ; Wed, 10 Jan 2024 00:28:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41C196B00AE; Tue, 9 Jan 2024 19:28:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CC8B6B00AF; Tue, 9 Jan 2024 19:28:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26C566B00B0; Tue, 9 Jan 2024 19:28:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 187306B00AE for ; Tue, 9 Jan 2024 19:28:31 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CA7344043D for ; Wed, 10 Jan 2024 00:28:30 +0000 (UTC) X-FDA: 81661515180.14.566DA66 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf08.hostedemail.com (Postfix) with ESMTP id 11B0E16000B for ; Wed, 10 Jan 2024 00:28:27 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=EOP5XOXA; spf=pass (imf08.hostedemail.com: domain of hao.xiang@bytedance.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=hao.xiang@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704846509; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H4pmETOHyhvCYkpQt+yPZYyBaRugInkKS3WBUZ/57JU=; b=QNZ2qyIFQXAnEwRA//RybfWNrhCbGP3ZjBWpDoJfNIfG2PIiwWHiVbNG6U7Eu6+W4DXQgJ ySYzkZ+KUnRq9rZndqfT3CKJDumVz7LB++itWUvFphHgzl5TfQ0GLgTUkAfvYKBEmZI5JB W9VoJRutNFmUbf9XdubmyexR8tuYzDk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704846509; a=rsa-sha256; cv=none; b=PM2YZE1iu6wRbVXpFzmWjIajtxkrdmt8c4UpShkuTz3H/UZs5o98rK8N7drVVcjj9k2jfL KV46bD3YNqF56qkEt1f0K/vKA3ugwp4yTRL8wUXJ7BFWrz+Yae6yEYyHozZQBQj0kLU866 IvAJmBwjDee/NotZcLEUw1DWLcPJ+Vw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=EOP5XOXA; spf=pass (imf08.hostedemail.com: domain of hao.xiang@bytedance.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=hao.xiang@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5534dcfdd61so6357460a12.0 for ; Tue, 09 Jan 2024 16:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1704846506; x=1705451306; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H4pmETOHyhvCYkpQt+yPZYyBaRugInkKS3WBUZ/57JU=; b=EOP5XOXAyEkC1oGiwCOWyOwunuIHrEnpYqpBm+RodiijvqNC0UY9LrNc003moDCGZl muEfsv96Yy7qBAPNWaxG6DnkkTJi/u27hDneCFqwndf4DIjMUffuqTtHFWUlz7RCBP+0 fGE2xPqgNCGWqZyCyvozVs7KAV6Vk07pNa8GxhZ5DZxU4ClZmxQnDux2v+p+EghloBvV jqTFvLY3qq+r/CMiPpf0k/RAb8+j362kyHJEeLyLjn39kHV126+Aj6X1bsGhQ8ViXRUC UpaDqck4c2JqkjOhDfjhLXFQa/HczFYF510INkVeVPV4HIvV7bMBt44qF7Pcj2gLrevf SC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704846506; x=1705451306; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H4pmETOHyhvCYkpQt+yPZYyBaRugInkKS3WBUZ/57JU=; b=vTNXzA+PxTCJlmssMhes+OfrSJzSdWyVMDFBZvbDt+543P4CaNvoDH3sB6s9WWyqfl GWiSBhrellg3qzTRx3TK3ecXJzFqlWfq4GUh97bzM8fTbLUaPBDzBu5QHYThBIPvF5A8 QQh/Ce7lQ6/JCDNG9lHINTakrcyhQkylPDFTIEP8JXnyqo/xBfeVynXOaVAgNk6KvgBE 9BunQXrhASGGSxwI+xndgR0MWBZ9meEtrC2KlUd6+UQTK8EZ8CHFvWctkknAC/wJZywz vBTlhaDVHe+kEfxZGitsCgE50/0XAsXJkXbN9nnvLw02DwnSdb3p5JchF+vx98G8lAmx 6fcQ== X-Gm-Message-State: AOJu0YwwJjhO6sPatzEIdMKOdI3bWpdbBrCk2UU4mOjoexLIkFgiXPSu 3UEYWvQFjOgIX0REHHswm4yLBhmyaBOJB52LqIY+hzcLlEqYBQ== X-Google-Smtp-Source: AGHT+IEn5QFPnpdbTlRy8zQfT/RyATV6pAFg6InDKMm2y7syoVXBkmePPkCqoJPOzTHgZl3vPqXyduVqupZ7sYtIL7U= X-Received: by 2002:a50:f615:0:b0:554:8c9d:c3ff with SMTP id c21-20020a50f615000000b005548c9dc3ffmr299258edn.29.1704846506388; Tue, 09 Jan 2024 16:28:26 -0800 (PST) MIME-Version: 1.0 References: <87fs00njft.fsf@yhuang6-desk2.ccr.corp.intel.com> <87edezc5l1.fsf@yhuang6-desk2.ccr.corp.intel.com> <87a5pmddl5.fsf@yhuang6-desk2.ccr.corp.intel.com> <87wmspbpma.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o7dv897s.fsf@yhuang6-desk2.ccr.corp.intel.com> <20240109155049.00003f13@Huawei.com> In-Reply-To: From: Hao Xiang Date: Tue, 9 Jan 2024 16:28:15 -0800 Message-ID: Subject: Re: [External] Re: [EXT] Re: [RFC PATCH v2 0/2] Node migration between memory tiers To: Gregory Price Cc: Jonathan Cameron , "Huang, Ying" , Srinivasulu Thanneeru , Srinivasulu Opensrc , "linux-cxl@vger.kernel.org" , "linux-mm@kvack.org" , "aneesh.kumar@linux.ibm.com" , "dan.j.williams@intel.com" , "mhocko@suse.com" , "tj@kernel.org" , "john@jagalactic.com" , Eishan Mirakhur , Vinicius Tavares Petrucci , Ravis OpenSrc , "linux-kernel@vger.kernel.org" , Johannes Weiner , Wei Xu , "Ho-Ren (Jack) Chuang" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: wxh8mcro1g7trcdjqdz8rpqmp71jc59k X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 11B0E16000B X-Rspam-User: X-HE-Tag: 1704846507-515245 X-HE-Meta: U2FsdGVkX1+71KGoJKn3F2+vmfdwZ6e6cigXfr9M3aFdkbJk0MV3WX0lB+xWsjWlpjq4sSHRuAjOpf2OqYD77b3N+IWXhEeIotxdR3akjQ6wYPUoTID9llt/qxCgV5g7UDkSC8FPaKFNljhHqqu237Shkr6wP21idcd8Wd4gCH4yvlI6PFXvFRHbFzAZOJJ8PI66IGAcu2ZzFUz2XrVzASlgMmaa5tfA7T1m0fHSbugVU1oQCdxkFQ5oaDeY68TX9e+Dj6KvIc6w+AvrWebvEyd1GfxAVE4Vsxib+pgJNDszW7aEPoqpFhgKSpU6pu7uphLHbVxPVwI9yTgZs9liNYFTIvUaA5Izi60ICsfj8RBgSl6Qa1MgMJDXO4Kx+3GJXUnqDkzouB5PnFc+AW6iLU0GIlMNTrk4MNqqY8fsPu2ApbmtDHzE1aLYvVee9k3sXJx+buGZ/RulNxjLtyT+GqGsIvuVNGRNw9u8YyXZvo95Nm0JuMkK0FYAZQLdJJVbEmO6e5Ka6fHSskeoxu/MqXpl79qhA2jTDvHYP0D9qrDCc52dH4VEbFPX4Hudx4MixUa5lTLZNcDoUdl/ZEYW0N8cUOWLeghhhBMvt3SyrNkODWaspUy4OGXZg4ku8lOqLUoOBAI7Qgzlfw3QPFMsG3Tun5KF5M3U7NUst0L3dSmBvaOW59g93R/gssl9+CzqvlYAkaub2WQryfgw/fIUec+h5xNHIdpggXUZr5sJ1/WjVk1Z6wDNN5oTr5JrjeuCfI8WeXUqbE4BgUuP/6vX8owDWdK9kGhA0/4jR45teutaZZhJqEstWskEl93pLxPHjJazgLgHScp2f5bw7A4TfYlrOAg2gykLDhkQXgbsWyeGAydp05GYnktoP6AqMCA41gj/TR2Mc6Y5F/t12wP7i+lZdTHErFCvUznojhiyWsm8g8d3ayf19eevR9tC2xvbHQrF56OSZcVQ4JzyNc7 zDZE8DDh 9Jpgg5VI7maz84fu5VhSGmBxBjy0BTAz/4/hU7p6Pjct+U7/iqao41gM+Dv8oBVW07dXC5pGs2RjB5Gu2ld6eGxY1/zZuYfYftdRo9rQDPxVxvW6lsdCyNm8zmT+XRfVnXb12BAyyjROPb0AI/BtgEkPEXRM2DWoHSWMCiPKDApRDJDRvqCF78P1LFPtNs+JGtcswCrKkjVwexSBw4/3crQnffhjCFYTgC22dxvW++/iOGkjruLS09SlXyQAJllwug/lJOAmC4p2D+42U0PIPTJmfO7M8wdaVcIGFQ/YmYbiWzLGwfd78+2GkFfPAHYKn1I38esKaOw8AliFFZFspgKbqZjYjf2l+al4LfnmLjs6zrEkWf5VWjS0CBttC59sMGN44dFmUGHV/VXVEqdS6PBjMLp2/cJpjdT00YNJ72qZ2GpmSWZ81Ic9rvlX2VioL6x0g 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, Jan 9, 2024 at 9:59=E2=80=AFAM Gregory Price wrote: > > On Tue, Jan 09, 2024 at 03:50:49PM +0000, Jonathan Cameron wrote: > > On Tue, 09 Jan 2024 11:41:11 +0800 > > "Huang, Ying" wrote: > > > Gregory Price writes: > > > > On Thu, Jan 04, 2024 at 02:05:01PM +0800, Huang, Ying wrote: > > > It's possible to change the performance of a NUMA node changed, if we > > > hot-remove a memory device, then hot-add another different memory > > > device. It's hoped that the CDAT changes too. > > > > Not supported, but ACPI has _HMA methods to in theory allow changing > > HMAT values based on firmware notifications... So we 'could' make > > it work for HMAT based description. > > > > Ultimately my current thinking is we'll end up emulating CXL type3 > > devices (hiding topology complexity) and you can update CDAT but > > IIRC that is only meant to be for degraded situations - so if you > > want multiple performance regions, CDAT should describe them form the s= tart. > > > > That was my thought. I don't think it's particularly *realistic* for > HMAT/CDAT values to change at runtime, but I can imagine a case where > it could be valuable. > > > > > https://lore.kernel.org/linux-cxl/CAAYibXjZ0HSCqMrzXGv62cMLncS_81R3= e1uNV5Fu4CPm0zAtYw@mail.gmail.com/ > > > > > > > > This group wants to enable passing CXL memory through to KVM/QEMU > > > > (i.e. host CXL expander memory passed through to the guest), and > > > > allow the guest to apply memory tiering. > > > > > > > > There are multiple issues with this, presently: > > > > > > > > 1. The QEMU CXL virtual device is not and probably never will be > > > > performant enough to be a commodity class virtualization. > > > > I'd flex that a bit - we will end up with a solution for virtualization= but > > it isn't the emulation that is there today because it's not possible to > > emulate some of the topology in a peformant manner (interleaving with s= ub > > page granularity / interleaving at all (to a lesser degree)). There are > > ways to do better than we are today, but they start to look like > > software dissagregated memory setups (think lots of page faults in the = host). > > > > Agreed, the emulated device as-is can't be the virtualization device, > but it doesn't mean it can't be the basis for it. > > My thought is, if you want to pass host CXL *memory* through to the > guest, you don't actually care to pass CXL *control* through to the > guest. That control lies pretty squarely with the host/hypervisor. > > So, at least in theory, you can just cut the type3 device out of the > QEMU configuration entirely and just pass it through as a distinct numa > node with specific hmat qualities. > > Barring that, if we must go through the type3 device, the question is > how difficult would it be to just make a stripped down type3 device > to provide the informational components, but hack off anything > topology/interleave related? Then you just do direct passthrough as you > described below. > > qemu/kvm would report errors if you tried to touch the naughty bits. > > The second question is... is that device "compliant" or does it need > super special handling from the kernel driver :D? If what i described > is not "compliant", then it's probably a bad idea, and KVM/QEMU should > just hide the CXL device entirely from the guest (for this use case) > and just pass the memory through as a numa node. > > Which gets us back to: The memory-tiering component needs a way to > place nodes in different tiers based on HMAT/CDAT/User Whim. All three > of those seem like totally valid ways to go about it. > > > > > > > > > 2. When passing memory through as an explicit NUMA node, but not as > > > > part of a CXL memory device, the nodes are lumped together in th= e > > > > DRAM tier. > > > > > > > > None of this has to do with firmware. > > > > > > > > Memory-type is an awful way of denoting membership of a tier, but w= e > > > > have HMAT information that can be passed through via QEMU: > > > > > > > > -object memory-backend-ram,size=3D4G,id=3Dram-node0 \ > > > > -object memory-backend-ram,size=3D4G,id=3Dram-node1 \ > > > > -numa node,nodeid=3D0,cpus=3D0-4,memdev=3Dram-node0 \ > > > > -numa node,initiator=3D0,nodeid=3D1,memdev=3Dram-node1 \ > > > > -numa hmat-lb,initiator=3D0,target=3D0,hierarchy=3Dmemory,data-type= =3Daccess-latency,latency=3D10 \ > > > > -numa hmat-lb,initiator=3D0,target=3D0,hierarchy=3Dmemory,data-type= =3Daccess-bandwidth,bandwidth=3D10485760 \ > > > > -numa hmat-lb,initiator=3D0,target=3D1,hierarchy=3Dmemory,data-type= =3Daccess-latency,latency=3D20 \ > > > > -numa hmat-lb,initiator=3D0,target=3D1,hierarchy=3Dmemory,data-type= =3Daccess-bandwidth,bandwidth=3D5242880 > > > > > > > > Not only would it be nice if we could change tier membership based = on > > > > this data, it's realistically the only way to allow guests to accom= plish > > > > memory tiering w/ KVM/QEMU and CXL memory passed through to the gue= st. > > > > This I fully agree with. There will be systems with a bunch of normal = DDR with different > > access characteristics irrespective of CXL. + likely HMAT solutions wil= l be used > > before we get anything more complex in place for CXL. > > > > Had not even considered this, but that's completely accurate as well. > > And more discretely: What of devices that don't provide HMAT/CDAT? That > isn't necessarily a violation of any standard. There probably could be > a release valve for us to still make those devices useful. > > The concern I have with not implementing a movement mechanism *at all* > is that a one-size-fits-all initial-placement heuristic feels gross > when we're, at least ideologically, moving toward "software defined memor= y". > > Personally I think the movement mechanism is a good idea that gets folks > where they're going sooner, and it doesn't hurt anything by existing. We > can change the initial placement mechanism too. I think providing users a way to "FIX" the memory tiering is a backup option. Given that DDRs with different access characteristics provide the relevant CDAT/HMAT information, the kernel should be able to correctly establish memory tiering on boot. Current memory tiering code has 1) memory_tier_init() to iterate through all boot onlined memory nodes. All nodes are assumed to be fast tier (adistance MEMTIER_ADISTANCE_DRAM is used). 2) dev_dax_kmem_probe to iterate through all devdax controlled memory nodes. This is the place the kernel reads the memory attributes from HMAT and recognizes the memory nodes into the correct tier (devdax controlled CXL, pmem, etc). If we want DDRs with different memory characteristics to be put into the correct tier (as in the guest VM memory tiering case), we probably need a third path to iterate the boot onlined memory nodes and also be able to read their memory attributes. I don't think we can do that in 1) because the ACPI subsystem is not yet initialized. > > > > ~Gregory