From: Dave Hansen <dave.hansen@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Keith Busch <keith.busch@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux API <linux-api@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCHv6 07/10] acpi/hmat: Register processor domain to its memory
Date: Wed, 20 Feb 2019 14:11:10 -0800 [thread overview]
Message-ID: <9ab5d6ba-4cb6-a6f1-894d-d79b77c8bc21@intel.com> (raw)
In-Reply-To: <CAJZ5v0gjv0DZvYMTPBLnUmMtu8=g0zFd4x-cpP11Kzv+6XCwUw@mail.gmail.com>
On 2/20/19 2:02 PM, Rafael J. Wysocki wrote:
>> diff --git a/drivers/acpi/hmat/Kconfig b/drivers/acpi/hmat/Kconfig
>> index c9637e2e7514..08e972ead159 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 to do this here, I'm not sure that defining HMEM_REPORTING
> as a user-selectable option is a good idea. In particular, I don't
> really think that setting ACPI_HMAT without it makes a lot of sense.
> Apart from this, the patch looks reasonable to me.
I guess the question is whether we would want to allow folks to consume
the HMAT inside the kernel while not reporting it out via
HMEM_REPORTING. We have some in-kernel users of the HMAT lined up like
mitigations for memory-side caches.
It's certainly possible that folks would want to consume those
mitigations without anything in sysfs. They might not even want or need
NUMA support itself, for instance.
So, what should we do?
config HMEM_REPORTING
bool # no user-visible prompt
default y if ACPI_HMAT
So folks can override in their .config, but they don't see a prompt?
next prev parent reply other threads:[~2019-02-20 22:11 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 17:10 [PATCHv6 00/10] Heterogenous memory node attributes Keith Busch
2019-02-14 17:10 ` [PATCHv6 01/10] acpi: Create subtable parsing infrastructure Keith Busch
2019-02-14 17:10 ` [PATCHv6 02/10] acpi: Add HMAT to generic parsing tables Keith Busch
2019-02-14 17:10 ` [PATCHv6 03/10] acpi/hmat: Parse and report heterogeneous memory Keith Busch
2019-02-14 17:10 ` [PATCHv6 04/10] node: Link memory nodes to their compute nodes Keith Busch
2019-02-14 17:10 ` [PATCHv6 05/10] node: Add heterogenous memory access attributes Keith Busch
2019-02-14 17:10 ` [PATCHv6 06/10] node: Add memory-side caching attributes Keith Busch
2019-02-22 10:12 ` Brice Goglin
2019-02-22 18:09 ` Keith Busch
2019-02-22 18:20 ` Dan Williams
2019-02-22 10:22 ` Brice Goglin
2019-02-22 18:13 ` Keith Busch
2019-02-14 17:10 ` [PATCHv6 07/10] acpi/hmat: Register processor domain to its memory Keith Busch
2019-02-20 22:02 ` Rafael J. Wysocki
2019-02-20 22:11 ` Dave Hansen [this message]
2019-02-20 22:13 ` Dan Williams
2019-02-20 22:16 ` Rafael J. Wysocki
2019-02-20 22:20 ` Dan Williams
2019-02-20 22:21 ` Rafael J. Wysocki
2019-02-20 22:44 ` Keith Busch
2019-02-20 22:50 ` Rafael J. Wysocki
2019-02-22 18:48 ` Keith Busch
2019-02-22 19:21 ` Dan Williams
2019-02-24 20:07 ` Rafael J. Wysocki
2019-02-24 19:59 ` Rafael J. Wysocki
2019-02-25 16:51 ` Keith Busch
2019-02-25 22:30 ` Rafael J. Wysocki
2019-03-07 11:49 ` Brice Goglin
2019-03-07 15:19 ` Keith Busch
2019-02-14 17:10 ` [PATCHv6 08/10] acpi/hmat: Register performance attributes Keith Busch
2019-02-20 22:04 ` Rafael J. Wysocki
2019-02-14 17:10 ` [PATCHv6 09/10] acpi/hmat: Register memory side cache attributes Keith Busch
2019-02-20 22:05 ` Rafael J. Wysocki
2019-02-14 17:10 ` [PATCHv6 10/10] doc/mm: New documentation for memory performance Keith Busch
2019-02-18 14:25 ` [PATCHv6 00/10] Heterogenous memory node attributes Brice Goglin
2019-02-19 17:20 ` Keith Busch
2019-02-20 18:25 ` Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ab5d6ba-4cb6-a6f1-894d-d79b77c8bc21@intel.com \
--to=dave.hansen@intel.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=keith.busch@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).