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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 629B9C2D0CD for ; Wed, 18 Dec 2019 14:50:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2FEA324650 for ; Wed, 18 Dec 2019 14:50:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FEA324650 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=Huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BC4648E0115; Wed, 18 Dec 2019 09:50:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B75648E00F5; Wed, 18 Dec 2019 09:50:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A63C08E0115; Wed, 18 Dec 2019 09:50:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0234.hostedemail.com [216.40.44.234]) by kanga.kvack.org (Postfix) with ESMTP id 8D0E08E00F5 for ; Wed, 18 Dec 2019 09:50:50 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 17B558249980 for ; Wed, 18 Dec 2019 14:50:50 +0000 (UTC) X-FDA: 76278549060.19.sheep05_5e8be98136519 X-HE-Tag: sheep05_5e8be98136519 X-Filterd-Recvd-Size: 4932 Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Dec 2019 14:50:49 +0000 (UTC) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 250F02B0021CA52D4578; Wed, 18 Dec 2019 14:50:43 +0000 (GMT) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Dec 2019 14:50:42 +0000 Received: from localhost (10.202.226.57) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5; Wed, 18 Dec 2019 14:50:42 +0000 Date: Wed, 18 Dec 2019 14:50:41 +0000 From: Jonathan Cameron To: Brice Goglin CC: , , , , , Keith Busch , , "Rafael J . Wysocki" , , "Andrew Morton" , Dan Williams , Tao Xu , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla Subject: Re: [PATCH V6 0/7] ACPI: Support Generic Initiator proximity domains Message-ID: <20191218145041.00005a11@Huawei.com> In-Reply-To: References: <20191216153809.105463-1-Jonathan.Cameron@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.202.226.57] X-ClientProxiedBy: lhreml706-chm.china.huawei.com (10.201.108.55) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected 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: On Wed, 18 Dec 2019 12:32:06 +0100 Brice Goglin wrote: > Le 16/12/2019 =E0 16:38, Jonathan Cameron a =E9crit=A0: > > Introduces a new type of NUMA node for cases where we want to represent > > the access characteristics of a non CPU initiator of memory requests, > > as these differ from all those for existing nodes containing CPUs and/or > > memory. > > > > These Generic Initiators are presented by the node access0 class in > > sysfs in the same way as a CPU. It seems likely that there will be > > usecases in which the best 'CPU' is desired and Generic Initiators > > should be ignored. The final few patches in this series introduced > > access1 which is a new performance class in the sysfs node description > > which presents only CPU to memory relationships. Test cases for this > > are described below. =20 >=20 >=20 > Hello Jonathan >=20 > If I want to test this with a fake GI, what are the minimal set of > changes I should put in my ACPI tables? Can I just specify a dummy GI in > SRAT? What handle should I use there? Exactly that for a dummy GI. Also extend HMAT and SLIT for the extra proximity domain / initiator. For the handle, anything is fine. This patch set doesn't currently use it. That handle was a bit controversial when this spec feature was being discussed because it can 'disagree' with information from _PXM. The ACPI spec ended up effectively relying on them agreeing. So any handle must identify a device that either doesn't have a _PXM entry or that has one that refers to the same proximity domain. Also note there is a fiddly corner case which is covered by an _OSC. If you have a device that you want to use _PXM to put in a GI only domain then older kernels will not know about the GI domain. Hence ACPI goes through a dance to ensure that a kernel that hasn't announced it is GI aware, doesn't get told anything is in a GI only domain. For testing this series though you can just ignore that. The logic to actually pass that handle based specification through to the devices is complex, so this set relies on _PXM in DSDT to actually associate any device with the Generic Initiator domain. If doing this for a PCI device, note that you need the fix mentioned in the cover letter to actually have _PXM apply to PCI EPs. Note that the _PXM case needs to work anyway as you might have a GI node with multiple GIs and there is no obligation for them all to be specified in SRAT. Once this initial set is in place we can work out how to use the SRAT handle to associate it with a device. To be honest, I haven't really thought about how we'd do that yet. Thanks, Jonathan >=20 > Thanks >=20 > Brice >=20 >=20