From: Tao Xu <tao3.xu@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>,
Len Brown <lenb@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
Date: Tue, 10 Dec 2019 21:18:47 +0800 [thread overview]
Message-ID: <82e7361e-256e-002c-6b30-601cec1fad07@intel.com> (raw)
In-Reply-To: <CAJZ5v0h6_7AoYW5Syk=BUR656eW11A3GjA7uvmTA6ayByOaqBg@mail.gmail.com>
On 12/10/2019 4:27 PM, Rafael J. Wysocki wrote:
> On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <tao3.xu@intel.com> wrote:
>>
>> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
>>> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <tao3.xu@intel.com> wrote:
>>>>
>>>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
>>>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <tao3.xu@intel.com> wrote:
>>>>>>
>>>>>> In chapter 5.2.27.5, Table 5-147: Field "Cache Attributes" of
>>>>>> ACPI 6.3 spec: 0 is "None", 1 is "Direct Mapped", 2 is "Complex Cache
>>>>>> Indexing" for Cache Associativity; 0 is "None", 1 is "Write Back",
>>>>>> 2 is "Write Through" for Write Policy.
>>>>>
>>>>> Well, I'm not sure what the connection between the above statement,
>>>>> which is correct AFAICS, and the changes made by the patch is.
>>>>>
>>>>> Is that the *_OTHER symbol names are confusing or something deeper?
>>>>>
>>>>
>>>> Because in include/acpi/actbl1.h:
>>>>
>>>> #define ACPI_HMAT_CA_NONE (0)
>>>>
>>>> ACPI_HMAT_CA_NONE is 0, but in include/linux/node.h:
>>>>
>>>> enum cache_indexing {
>>>> NODE_CACHE_DIRECT_MAP,
>>>> NODE_CACHE_INDEXED,
>>>> NODE_CACHE_OTHER,
>>>> };
>>>> NODE_CACHE_OTHER is 2, and for otner enum:
>>>>
>>>> case ACPI_HMAT_CA_DIRECT_MAPPED:
>>>> tcache->cache_attrs.indexing = NODE_CACHE_DIRECT_MAP;
>>>> break;
>>>> case ACPI_HMAT_CA_COMPLEX_CACHE_INDEXING:
>>>> tcache->cache_attrs.indexing = NODE_CACHE_INDEXED;
>>>> break;
>>>> in include/acpi/actbl1.h:
>>>>
>>>> #define ACPI_HMAT_CA_DIRECT_MAPPED (1)
>>>> #define ACPI_HMAT_CA_COMPLEX_CACHE_INDEXING (2)
>>>>
>>>> but in include/linux/node.h:
>>>>
>>>> NODE_CACHE_DIRECT_MAP is 0, NODE_CACHE_INDEXED is 1. This is incorrect.
>>>
>>> Why is it incorrect?
>>
>> Sorry I paste the wrong pre-define.
>>
>> This is the incorrect line:
>>
>> case ACPI_HMAT_CA_DIRECT_MAPPED:
>> tcache->cache_attrs.indexing = NODE_CACHE_DIRECT_MAP;
>>
>> ACPI_HMAT_CA_DIRECT_MAPPED is 1, NODE_CACHE_DIRECT_MAP is 0. That means
>> if HMAT table input 1 for cache_attrs.indexing, kernel store 0 in
>> cache_attrs.indexing. But in ACPI 6.3, 0 means "None". So for the whole
>> switch codes:
>
> This is a mapping between the ACPI-defined values and the generic ones
> defined in the kernel. There is not rule I know of by which they must
> be the same numbers. Or is there such a rule which I'm missing?
>
> As long as cache_attrs.indexing is used consistently going forward,
> the difference between the ACPI-defined numbers and its values
> shouldn't matter, should it?
>
Yes, it will not influence the ACPI HMAT tables. Only influence is the
sysfs, as in
https://www.kernel.org/doc/html/latest/admin-guide/mm/numaperf.html:
# tree sys/devices/system/node/node0/memory_side_cache/
/sys/devices/system/node/node0/memory_side_cache/
|-- index1
| |-- indexing
| |-- line_size
| |-- size
| `-- write_policy
indexing is parsed in this file, so it can be read by user-space.
Although now there is no user-space tool use this information to do some
thing. But I am wondering if it is used in the future, someone use it to
show the memory side cache information to user or use it to do
performance turning.
next prev parent reply other threads:[~2019-12-10 13:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 7:03 [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy Tao Xu
2019-12-09 7:43 ` Tao Xu
2019-12-09 7:55 ` Greg KH
2019-12-09 8:38 ` Tao Xu
2019-12-09 10:01 ` Rafael J. Wysocki
2019-12-10 1:04 ` Tao Xu
2019-12-10 8:06 ` Rafael J. Wysocki
2019-12-10 8:19 ` Tao Xu
2019-12-10 8:27 ` Rafael J. Wysocki
2019-12-10 13:18 ` Tao Xu [this message]
2019-12-11 3:04 ` Tao Xu
2019-12-11 3:37 ` Dan Williams
2019-12-11 4:27 ` Tao Xu
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=82e7361e-256e-002c-6b30-601cec1fad07@intel.com \
--to=tao3.xu@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--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).