Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2044631imu; Thu, 17 Jan 2019 07:30:40 -0800 (PST) X-Google-Smtp-Source: ALg8bN5blTF4L47P1hOTxILqM7un+XqM5VRPBhFLzR1qcYsdlVPYDVmo9ry0jzCgGhivgALvJz+X X-Received: by 2002:a17:902:7896:: with SMTP id q22mr15626446pll.280.1547739039945; Thu, 17 Jan 2019 07:30:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547739039; cv=none; d=google.com; s=arc-20160816; b=pVLL+43Jre0rulwi/ts4GioCOX/yUzGUGFYTJ4eR163QRmPplSzkoTyWJi/Vtopu1U 7+ONXv8zAD+PS0dbgjn4FSikcH3XPqqXKOt4Ft5j7AGZiM2uowY9NC/mFh81UI6qZZz1 7aCRkCbwZGxS0T3CoNsITCtQCnuFh0xjIJ4Hx1IoztQCpgmqyNfG52iSBzeFw5zXjokv 4vS8xeToEvDXOIzhf/hmIMnZaD/TqvpoE55MumlVGttH85sAqnXaD8i/TV2Ubr2endHb 0nrdTN8P07DLcVePnEdaHjklSnJkbVAVUeLgQrkHw867PyFqAihvcNc7uSDWPB4AoQJB Tr5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=gO0CRcGYzFQ3a4ks8/KW/sDVv+Nz1F5Jm24CDMNgFDM=; b=fVpYybDuqVw8Ma3YB7J/1jAFcnmscByaca1R/E9zlUN2Q2FziR/f81ymZPkE79yUia 9aSZjWKqeYCUtG4j5Lmm4G7J1t2fdS/v8e7EnmoCb8hr6fArWF+kjhCUTb+OAfa4XvM6 kDNYWniVsh+5Ygk6I8uZ1hetynxaA/q/2k08awGjZYsCSW6kXM4oQGwy/HnU0KuUgwB8 VpQNVajtu16hvsebkShViy3ZpXRnaIkS2IsEgRmPo2ZkY1/kbPnATXJDN+bYFff28TsE LHohozyrdD6bMGTe3NCfj/SDVjMaMUG2N6tGJI9OuqPUUSJxQGHi/wJo7JMBkiIFsD82 GyJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 39si1989198pla.352.2019.01.17.07.30.20; Thu, 17 Jan 2019 07:30:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728404AbfAQPVa (ORCPT + 99 others); Thu, 17 Jan 2019 10:21:30 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:44259 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727306AbfAQPV3 (ORCPT ); Thu, 17 Jan 2019 10:21:29 -0500 Received: by mail-oi1-f194.google.com with SMTP id m6so6394203oig.11; Thu, 17 Jan 2019 07:21:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gO0CRcGYzFQ3a4ks8/KW/sDVv+Nz1F5Jm24CDMNgFDM=; b=ci9lTKCiW8AlmY1lot0S5jr8KBM4HL7GZFaHOPyiaxKI8UKO6DMbmHkgK2w7IWTXt/ dNOu+/Y57m0PSTjMzRimZRg9kI2DXS/XPl/BDOoc0Q6Q3qfgW25S3BDrUz08tFhyP345 VSr5XThZLPaJJFxpU2CpoHIdjpKo7h0viD7uXKFDW/hN0GdPRjDcAOVpBQjVnvY+zAvE afnCKUNNT5uKtmGsHAGlohM4Szvn0bOkTYXtVm7EY1lqZy3YyBp2rKeDDbwXhhQBA026 /Z83XnXR/LdYv+1awUzXKNHddx8xKGxt9F/IkPR7FSakEYi/muMwBZo4d+JxYJbrqgv3 mgbQ== X-Gm-Message-State: AJcUukcqzTuUMGY8qf9HEDBAdTFZAV5g8qlYzOMffpL+f0J4cre6ryDb 3yDyA8M2+1W/QnJ1mzcN2E326iUWCLWBZcpB0KQ= X-Received: by 2002:aca:e715:: with SMTP id e21mr8039215oih.76.1547738488501; Thu, 17 Jan 2019 07:21:28 -0800 (PST) MIME-Version: 1.0 References: <20190116175804.30196-1-keith.busch@intel.com> <20190116175804.30196-10-keith.busch@intel.com> In-Reply-To: <20190116175804.30196-10-keith.busch@intel.com> From: "Rafael J. Wysocki" Date: Thu, 17 Jan 2019 16:21:16 +0100 Message-ID: Subject: Re: [PATCHv4 09/13] acpi/hmat: Register performance attributes To: Keith Busch Cc: Linux Kernel Mailing List , ACPI Devel Maling List , Linux Memory Management List , Greg Kroah-Hartman , Rafael Wysocki , Dave Hansen , Dan Williams Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 16, 2019 at 6:59 PM Keith Busch wrote: > > Save the best performace access attributes and register these with the > memory's node if HMAT provides the locality table. While HMAT does make > it possible to know performance for all possible initiator-target > pairings, we export only the best pairings at this time. > > Signed-off-by: Keith Busch > --- > drivers/acpi/hmat/Kconfig | 1 + > drivers/acpi/hmat/hmat.c | 34 ++++++++++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+) > > diff --git a/drivers/acpi/hmat/Kconfig b/drivers/acpi/hmat/Kconfig > index a4034d37a311..20a0e96ba58a 100644 > --- a/drivers/acpi/hmat/Kconfig > +++ b/drivers/acpi/hmat/Kconfig > @@ -2,6 +2,7 @@ > config ACPI_HMAT > bool "ACPI Heterogeneous Memory Attribute Table Support" > depends on ACPI_NUMA > + select HMEM_REPORTING If you want HMEM_REPORTING to be only set when ACPI_HMAT is set, then don't make HMEM_REPORTING user-selectable. > help > Parses representation of the ACPI Heterogeneous Memory Attributes > Table (HMAT) and set the memory node relationships and access > diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c > index efb33c74d1a3..45e20dc677f9 100644 > --- a/drivers/acpi/hmat/hmat.c > +++ b/drivers/acpi/hmat/hmat.c > @@ -23,6 +23,8 @@ struct memory_target { > struct list_head node; > unsigned int memory_pxm; > unsigned long p_nodes[BITS_TO_LONGS(MAX_NUMNODES)]; > + bool hmem_valid; > + struct node_hmem_attrs hmem; > }; > > static __init struct memory_target *find_mem_target(unsigned int m) > @@ -108,6 +110,34 @@ static __init void hmat_update_access(u8 type, u32 value, u32 *best) > } > } > > +static __init void hmat_update_target(struct memory_target *t, u8 type, > + u32 value) > +{ > + switch (type) { > + case ACPI_HMAT_ACCESS_LATENCY: > + t->hmem.read_latency = value; > + t->hmem.write_latency = value; > + break; > + case ACPI_HMAT_READ_LATENCY: > + t->hmem.read_latency = value; > + break; > + case ACPI_HMAT_WRITE_LATENCY: > + t->hmem.write_latency = value; > + break; > + case ACPI_HMAT_ACCESS_BANDWIDTH: > + t->hmem.read_bandwidth = value; > + t->hmem.write_bandwidth = value; > + break; > + case ACPI_HMAT_READ_BANDWIDTH: > + t->hmem.read_bandwidth = value; > + break; > + case ACPI_HMAT_WRITE_BANDWIDTH: > + t->hmem.write_bandwidth = value; > + break; > + } > + t->hmem_valid = true; What if 'type' is none of the above? After all these values come from the firmware and that need not be correct. Do you still want to set hmem_valid in that case? > +} > + > static __init int hmat_parse_locality(union acpi_subtable_headers *header, > const unsigned long end) > { > @@ -166,6 +196,8 @@ static __init int hmat_parse_locality(union acpi_subtable_headers *header, > set_bit(p_node, t->p_nodes); > } > } > + if (t && best) > + hmat_update_target(t, type, best); > } > return 0; > } > @@ -267,6 +299,8 @@ static __init void hmat_register_targets(void) > m = pxm_to_node(t->memory_pxm); > for_each_set_bit(p, t->p_nodes, MAX_NUMNODES) > register_memory_node_under_compute_node(m, p, 0); > + if (t->hmem_valid) > + node_set_perf_attrs(m, &t->hmem, 0); > kfree(t); > } > } > --