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.
Signed-off-by: Tao Xu <[email protected]>
---
drivers/acpi/numa/hmat.c | 4 ++--
include/linux/node.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
index 2c32cfb72370..719d0279563d 100644
--- a/drivers/acpi/numa/hmat.c
+++ b/drivers/acpi/numa/hmat.c
@@ -383,7 +383,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
break;
case ACPI_HMAT_CA_NONE:
default:
- tcache->cache_attrs.indexing = NODE_CACHE_OTHER;
+ tcache->cache_attrs.indexing = NODE_CACHE_NONE;
break;
}
@@ -396,7 +396,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
break;
case ACPI_HMAT_CP_NONE:
default:
- tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_OTHER;
+ tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_NONE;
break;
}
list_add_tail(&tcache->node, &target->caches);
diff --git a/include/linux/node.h b/include/linux/node.h
index 4866f32a02d8..6dbd764d09ce 100644
--- a/include/linux/node.h
+++ b/include/linux/node.h
@@ -36,15 +36,15 @@ struct node_hmem_attrs {
};
enum cache_indexing {
+ NODE_CACHE_NONE,
NODE_CACHE_DIRECT_MAP,
NODE_CACHE_INDEXED,
- NODE_CACHE_OTHER,
};
enum cache_write_policy {
+ NODE_CACHE_WRITE_NONE,
NODE_CACHE_WRITE_BACK,
NODE_CACHE_WRITE_THROUGH,
- NODE_CACHE_WRITE_OTHER,
};
/**
--
2.20.1
Gentle ping :)
On 12/2/2019 3:03 PM, Tao Xu 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.
>
> Signed-off-by: Tao Xu <[email protected]>
> ---
> drivers/acpi/numa/hmat.c | 4 ++--
> include/linux/node.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
> index 2c32cfb72370..719d0279563d 100644
> --- a/drivers/acpi/numa/hmat.c
> +++ b/drivers/acpi/numa/hmat.c
> @@ -383,7 +383,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
> break;
> case ACPI_HMAT_CA_NONE:
> default:
> - tcache->cache_attrs.indexing = NODE_CACHE_OTHER;
> + tcache->cache_attrs.indexing = NODE_CACHE_NONE;
> break;
> }
>
> @@ -396,7 +396,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
> break;
> case ACPI_HMAT_CP_NONE:
> default:
> - tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_OTHER;
> + tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_NONE;
> break;
> }
> list_add_tail(&tcache->node, &target->caches);
> diff --git a/include/linux/node.h b/include/linux/node.h
> index 4866f32a02d8..6dbd764d09ce 100644
> --- a/include/linux/node.h
> +++ b/include/linux/node.h
> @@ -36,15 +36,15 @@ struct node_hmem_attrs {
> };
>
> enum cache_indexing {
> + NODE_CACHE_NONE,
> NODE_CACHE_DIRECT_MAP,
> NODE_CACHE_INDEXED,
> - NODE_CACHE_OTHER,
> };
>
> enum cache_write_policy {
> + NODE_CACHE_WRITE_NONE,
> NODE_CACHE_WRITE_BACK,
> NODE_CACHE_WRITE_THROUGH,
> - NODE_CACHE_WRITE_OTHER,
> };
>
> /**
>
On Mon, Dec 09, 2019 at 03:43:21PM +0800, Tao Xu wrote:
> Gentle ping :)
>
> On 12/2/2019 3:03 PM, Tao Xu 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.
> >
> > Signed-off-by: Tao Xu <[email protected]>
> > ---
> > drivers/acpi/numa/hmat.c | 4 ++--
> > include/linux/node.h | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
It was the middle of the merge window that just ended a few hours ago.
Please give maintainers a chance to catch up...
On 12/9/2019 3:55 PM, Greg KH wrote:
> On Mon, Dec 09, 2019 at 03:43:21PM +0800, Tao Xu wrote:
>> Gentle ping :)
>>
>> On 12/2/2019 3:03 PM, Tao Xu 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.
>>>
>>> Signed-off-by: Tao Xu <[email protected]>
>>> ---
>>> drivers/acpi/numa/hmat.c | 4 ++--
>>> include/linux/node.h | 4 ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> It was the middle of the merge window that just ended a few hours ago.
> Please give maintainers a chance to catch up...
>
I understand, thanks
On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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?
> Signed-off-by: Tao Xu <[email protected]>
> ---
> drivers/acpi/numa/hmat.c | 4 ++--
> include/linux/node.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
> index 2c32cfb72370..719d0279563d 100644
> --- a/drivers/acpi/numa/hmat.c
> +++ b/drivers/acpi/numa/hmat.c
> @@ -383,7 +383,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
> break;
> case ACPI_HMAT_CA_NONE:
> default:
> - tcache->cache_attrs.indexing = NODE_CACHE_OTHER;
> + tcache->cache_attrs.indexing = NODE_CACHE_NONE;
> break;
> }
>
> @@ -396,7 +396,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
> break;
> case ACPI_HMAT_CP_NONE:
> default:
> - tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_OTHER;
> + tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_NONE;
> break;
> }
> list_add_tail(&tcache->node, &target->caches);
> diff --git a/include/linux/node.h b/include/linux/node.h
> index 4866f32a02d8..6dbd764d09ce 100644
> --- a/include/linux/node.h
> +++ b/include/linux/node.h
> @@ -36,15 +36,15 @@ struct node_hmem_attrs {
> };
>
> enum cache_indexing {
> + NODE_CACHE_NONE,
> NODE_CACHE_DIRECT_MAP,
> NODE_CACHE_INDEXED,
> - NODE_CACHE_OTHER,
> };
>
> enum cache_write_policy {
> + NODE_CACHE_WRITE_NONE,
> NODE_CACHE_WRITE_BACK,
> NODE_CACHE_WRITE_THROUGH,
> - NODE_CACHE_WRITE_OTHER,
> };
>
> /**
On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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.
And same for enum cache_write_policy.
>> Signed-off-by: Tao Xu <[email protected]>
>> ---
>> drivers/acpi/numa/hmat.c | 4 ++--
>> include/linux/node.h | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
>> index 2c32cfb72370..719d0279563d 100644
>> --- a/drivers/acpi/numa/hmat.c
>> +++ b/drivers/acpi/numa/hmat.c
>> @@ -383,7 +383,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
>> break;
>> case ACPI_HMAT_CA_NONE:
>> default:
>> - tcache->cache_attrs.indexing = NODE_CACHE_OTHER;
>> + tcache->cache_attrs.indexing = NODE_CACHE_NONE;
>> break;
>> }
>>
>> @@ -396,7 +396,7 @@ static __init int hmat_parse_cache(union acpi_subtable_headers *header,
>> break;
>> case ACPI_HMAT_CP_NONE:
>> default:
>> - tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_OTHER;
>> + tcache->cache_attrs.write_policy = NODE_CACHE_WRITE_NONE;
>> break;
>> }
>> list_add_tail(&tcache->node, &target->caches);
>> diff --git a/include/linux/node.h b/include/linux/node.h
>> index 4866f32a02d8..6dbd764d09ce 100644
>> --- a/include/linux/node.h
>> +++ b/include/linux/node.h
>> @@ -36,15 +36,15 @@ struct node_hmem_attrs {
>> };
>>
>> enum cache_indexing {
>> + NODE_CACHE_NONE,
>> NODE_CACHE_DIRECT_MAP,
>> NODE_CACHE_INDEXED,
>> - NODE_CACHE_OTHER,
>> };
>>
>> enum cache_write_policy {
>> + NODE_CACHE_WRITE_NONE,
>> NODE_CACHE_WRITE_BACK,
>> NODE_CACHE_WRITE_THROUGH,
>> - NODE_CACHE_WRITE_OTHER,
>> };
>>
>> /**
On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
>
> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
> > On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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?
> And same for enum cache_write_policy.
On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
>>
>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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:
switch ((attrs & ACPI_HMAT_CACHE_ASSOCIATIVITY) >> 8) {
case ACPI_HMAT_CA_DIRECT_MAPPED(1):
tcache->cache_attrs.indexing = NODE_CACHE_DIRECT_MAP(0);
break;
case ACPI_HMAT_CA_COMPLEX_CACHE_INDEXING(2):
tcache->cache_attrs.indexing = NODE_CACHE_INDEXED(1);
break;
case ACPI_HMAT_CA_NONE(0):
default:
tcache->cache_attrs.indexing = NODE_CACHE_OTHER(2);
break;
}
On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <[email protected]> wrote:
>
> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
> > On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
> >>
> >> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
> >>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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?
>
> switch ((attrs & ACPI_HMAT_CACHE_ASSOCIATIVITY) >> 8) {
> case ACPI_HMAT_CA_DIRECT_MAPPED(1):
> tcache->cache_attrs.indexing = NODE_CACHE_DIRECT_MAP(0);
> break;
> case ACPI_HMAT_CA_COMPLEX_CACHE_INDEXING(2):
> tcache->cache_attrs.indexing = NODE_CACHE_INDEXED(1);
> break;
> case ACPI_HMAT_CA_NONE(0):
> default:
> tcache->cache_attrs.indexing = NODE_CACHE_OTHER(2);
> break;
> }
On 12/10/2019 4:27 PM, Rafael J. Wysocki wrote:
> On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <[email protected]> wrote:
>>
>> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
>>> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
>>>>
>>>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
>>>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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.
On 12/10/19 9:18 PM, Tao Xu wrote:
> On 12/10/2019 4:27 PM, Rafael J. Wysocki wrote:
>> On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <[email protected]> wrote:
>>>
>>> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
>>>> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
>>>>>
>>>>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
>>>>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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.
I finish a test using emulated ACPI HMAT from QEMU
(branch:hmat https://github.com/taoxu916/qemu.git)
And I get the kernel log and sysfs output:
[ 0.954288] HMAT: Cache: Domain:0 Size:20480 Attrs:00081111 SMBIOS
Handles:0
[ 0.954835] HMAT: Cache: Domain:1 Size:15360 Attrs:00081111 SMBIOS
Handles:0
/sys/devices/system/node/node0/memory_side_cache/index1 # cat indexing
0
/sys/devices/system/node/node0/memory_side_cache/index1 # cat write_policy
0
Note that 'Attrs' is printed using %x, so we can get:
(attrs & ACPI_HMAT_CACHE_ASSOCIATIVITY) >> 8 = 1,
(attrs & ACPI_HMAT_WRITE_POLICY) >> 12 = 1
but we get 0 in sysfs, so if user or software read this information and
read the ACPI 6.3 spec, will think there is 'none' for Cache
Associativity or Write Policy.
p.s. the qemu input CLI:
./x86_64-softmmu/qemu-system-x86_64 \
-machine pc,hmat=on -nographic \
-kernel ./bzImage \
-initrd ./initramfs-virt \
-append console=ttyS0 \
-m 2G \
-smp 2,sockets=2 \
-object memory-backend-ram,size=1G,id=m0 \
-object memory-backend-ram,size=1G,id=m1 \
-numa node,nodeid=0,memdev=m0 \
-numa node,nodeid=1,memdev=m1,initiator=0 \
-numa cpu,node-id=0,socket-id=0 \
-numa cpu,node-id=0,socket-id=1 \
-numa
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=20
\
-numa
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M
\
-numa
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=65
\
-numa
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M
\
-numa
hmat-cache,node-id=0,size=20K,level=1,associativity=direct,policy=write-back,line=8
\
-numa
hmat-cache,node-id=1,size=15K,level=1,associativity=direct,policy=write-back,line=8
On Tue, Dec 10, 2019 at 7:05 PM Tao Xu <[email protected]> wrote:
>
>
> On 12/10/19 9:18 PM, Tao Xu wrote:
> > On 12/10/2019 4:27 PM, Rafael J. Wysocki wrote:
> >> On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <[email protected]> wrote:
> >>>
> >>> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
> >>>> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
> >>>>>
> >>>>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
> >>>>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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.
>
> I finish a test using emulated ACPI HMAT from QEMU
> (branch:hmat https://github.com/taoxu916/qemu.git)
>
> And I get the kernel log and sysfs output:
> [ 0.954288] HMAT: Cache: Domain:0 Size:20480 Attrs:00081111 SMBIOS
> Handles:0
> [ 0.954835] HMAT: Cache: Domain:1 Size:15360 Attrs:00081111 SMBIOS
> Handles:0
>
> /sys/devices/system/node/node0/memory_side_cache/index1 # cat indexing
> 0
> /sys/devices/system/node/node0/memory_side_cache/index1 # cat write_policy
> 0
>
> Note that 'Attrs' is printed using %x, so we can get:
> (attrs & ACPI_HMAT_CACHE_ASSOCIATIVITY) >> 8 = 1,
> (attrs & ACPI_HMAT_WRITE_POLICY) >> 12 = 1
>
> but we get 0 in sysfs, so if user or software read this information and
> read the ACPI 6.3 spec, will think there is 'none' for Cache
> Associativity or Write Policy.
The sysfs interface is not meant to reflect the ACPI values. This
sysfs information may be populated by another platform firmware
(non-ACPI). I would have preferred that these files use text values
rather than numbers. However, at least the ABI documentation gives the
expected translation:
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/indexing
Date: December 2018
Contact: Keith Busch <[email protected]>
Description:
The caches associativity indexing: 0 for direct mapped,
non-zero if indexed.
What:
/sys/devices/system/node/nodeX/memory_side_cache/indexY/write_policy
Date: December 2018
Contact: Keith Busch <[email protected]>
Description:
The cache write policy: 0 for write-back, 1 for write-through,
other or unknown.
On 12/11/2019 11:37 AM, Dan Williams wrote:
> On Tue, Dec 10, 2019 at 7:05 PM Tao Xu <[email protected]> wrote:
>>
>>
>> On 12/10/19 9:18 PM, Tao Xu wrote:
>>> On 12/10/2019 4:27 PM, Rafael J. Wysocki wrote:
>>>> On Tue, Dec 10, 2019 at 9:19 AM Tao Xu <[email protected]> wrote:
>>>>>
>>>>> On 12/10/2019 4:06 PM, Rafael J. Wysocki wrote:
>>>>>> On Tue, Dec 10, 2019 at 2:04 AM Tao Xu <[email protected]> wrote:
>>>>>>>
>>>>>>> On 12/9/2019 6:01 PM, Rafael J. Wysocki wrote:
>>>>>>>> On Mon, Dec 2, 2019 at 8:03 AM Tao Xu <[email protected]> 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.
>>
>> I finish a test using emulated ACPI HMAT from QEMU
>> (branch:hmat https://github.com/taoxu916/qemu.git)
>>
>> And I get the kernel log and sysfs output:
>> [ 0.954288] HMAT: Cache: Domain:0 Size:20480 Attrs:00081111 SMBIOS
>> Handles:0
>> [ 0.954835] HMAT: Cache: Domain:1 Size:15360 Attrs:00081111 SMBIOS
>> Handles:0
>>
>> /sys/devices/system/node/node0/memory_side_cache/index1 # cat indexing
>> 0
>> /sys/devices/system/node/node0/memory_side_cache/index1 # cat write_policy
>> 0
>>
>> Note that 'Attrs' is printed using %x, so we can get:
>> (attrs & ACPI_HMAT_CACHE_ASSOCIATIVITY) >> 8 = 1,
>> (attrs & ACPI_HMAT_WRITE_POLICY) >> 12 = 1
>>
>> but we get 0 in sysfs, so if user or software read this information and
>> read the ACPI 6.3 spec, will think there is 'none' for Cache
>> Associativity or Write Policy.
>
> The sysfs interface is not meant to reflect the ACPI values. This
> sysfs information may be populated by another platform firmware
> (non-ACPI). I would have preferred that these files use text values
> rather than numbers. However, at least the ABI documentation gives the
> expected translation:
>
> What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/indexing
> Date: December 2018
> Contact: Keith Busch <[email protected]>
> Description:
> The caches associativity indexing: 0 for direct mapped,
> non-zero if indexed.
>
> What:
> /sys/devices/system/node/nodeX/memory_side_cache/indexY/write_policy
> Date: December 2018
> Contact: Keith Busch <[email protected]>
> Description:
> The cache write policy: 0 for write-back, 1 for write-through,
> other or unknown.
>
I understand. Thank you for your explanation.