linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
@ 2019-12-02  7:03 Tao Xu
  2019-12-09  7:43 ` Tao Xu
  2019-12-09 10:01 ` Rafael J. Wysocki
  0 siblings, 2 replies; 13+ messages in thread
From: Tao Xu @ 2019-12-02  7:03 UTC (permalink / raw)
  To: rafael.j.wysocki, lenb, keith.busch, gregkh, dan.j.williams, dave.hansen
  Cc: linux-acpi, linux-kernel, Tao Xu

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 <tao3.xu@intel.com>
---
 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


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  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 10:01 ` Rafael J. Wysocki
  1 sibling, 1 reply; 13+ messages in thread
From: Tao Xu @ 2019-12-09  7:43 UTC (permalink / raw)
  To: rafael.j.wysocki, lenb, keith.busch, gregkh, dan.j.williams, dave.hansen
  Cc: linux-acpi, linux-kernel

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 <tao3.xu@intel.com>
> ---
>   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,
>   };
>   
>   /**
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-09  7:43 ` Tao Xu
@ 2019-12-09  7:55   ` Greg KH
  2019-12-09  8:38     ` Tao Xu
  0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2019-12-09  7:55 UTC (permalink / raw)
  To: Tao Xu
  Cc: rafael.j.wysocki, lenb, keith.busch, dan.j.williams, dave.hansen,
	linux-acpi, linux-kernel

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 <tao3.xu@intel.com>
> > ---
> >   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...


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-09  7:55   ` Greg KH
@ 2019-12-09  8:38     ` Tao Xu
  0 siblings, 0 replies; 13+ messages in thread
From: Tao Xu @ 2019-12-09  8:38 UTC (permalink / raw)
  To: Greg KH
  Cc: rafael.j.wysocki, lenb, dan.j.williams, dave.hansen, linux-acpi,
	linux-kernel

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 <tao3.xu@intel.com>
>>> ---
>>>    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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  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 10:01 ` Rafael J. Wysocki
  2019-12-10  1:04   ` Tao Xu
  1 sibling, 1 reply; 13+ messages in thread
From: Rafael J. Wysocki @ 2019-12-09 10:01 UTC (permalink / raw)
  To: Tao Xu
  Cc: Rafael Wysocki, Len Brown, Keith Busch, Greg Kroah-Hartman,
	Dan Williams, Dave Hansen, ACPI Devel Maling List,
	Linux Kernel Mailing List

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?

> Signed-off-by: Tao Xu <tao3.xu@intel.com>
> ---
>  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,
>  };
>
>  /**

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-09 10:01 ` Rafael J. Wysocki
@ 2019-12-10  1:04   ` Tao Xu
  2019-12-10  8:06     ` Rafael J. Wysocki
  0 siblings, 1 reply; 13+ messages in thread
From: Tao Xu @ 2019-12-10  1:04 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael Wysocki, Len Brown, Keith Busch, Greg Kroah-Hartman,
	Dan Williams, Dave Hansen, ACPI Devel Maling List,
	Linux Kernel Mailing List

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. 
And same for enum cache_write_policy.

>> Signed-off-by: Tao Xu <tao3.xu@intel.com>
>> ---
>>   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,
>>   };
>>
>>   /**


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-10  1:04   ` Tao Xu
@ 2019-12-10  8:06     ` Rafael J. Wysocki
  2019-12-10  8:19       ` Tao Xu
  0 siblings, 1 reply; 13+ messages in thread
From: Rafael J. Wysocki @ 2019-12-10  8:06 UTC (permalink / raw)
  To: Tao Xu
  Cc: Rafael J. Wysocki, Rafael Wysocki, Len Brown, Keith Busch,
	Greg Kroah-Hartman, Dan Williams, Dave Hansen,
	ACPI Devel Maling List, Linux Kernel Mailing List

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?

> And same for enum cache_write_policy.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-10  8:06     ` Rafael J. Wysocki
@ 2019-12-10  8:19       ` Tao Xu
  2019-12-10  8:27         ` Rafael J. Wysocki
  0 siblings, 1 reply; 13+ messages in thread
From: Tao Xu @ 2019-12-10  8:19 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael Wysocki, Len Brown, Greg Kroah-Hartman, Dan Williams,
	Dave Hansen, ACPI Devel Maling List, Linux Kernel Mailing List

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:

         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;
         }

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-10  8:19       ` Tao Xu
@ 2019-12-10  8:27         ` Rafael J. Wysocki
  2019-12-10 13:18           ` Tao Xu
  0 siblings, 1 reply; 13+ messages in thread
From: Rafael J. Wysocki @ 2019-12-10  8:27 UTC (permalink / raw)
  To: Tao Xu
  Cc: Rafael J. Wysocki, Rafael Wysocki, Len Brown, Greg Kroah-Hartman,
	Dan Williams, Dave Hansen, ACPI Devel Maling List,
	Linux Kernel Mailing List

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?

>
>          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;
>          }

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-10  8:27         ` Rafael J. Wysocki
@ 2019-12-10 13:18           ` Tao Xu
  2019-12-11  3:04             ` Tao Xu
  0 siblings, 1 reply; 13+ messages in thread
From: Tao Xu @ 2019-12-10 13:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael Wysocki, Len Brown, Greg Kroah-Hartman, Dan Williams,
	Dave Hansen, ACPI Devel Maling List, Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-10 13:18           ` Tao Xu
@ 2019-12-11  3:04             ` Tao Xu
  2019-12-11  3:37               ` Dan Williams
  0 siblings, 1 reply; 13+ messages in thread
From: Tao Xu @ 2019-12-11  3:04 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael Wysocki, Len Brown, Greg Kroah-Hartman, Dan Williams,
	Dave Hansen, ACPI Devel Maling List, Linux Kernel Mailing List


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 <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.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-11  3:04             ` Tao Xu
@ 2019-12-11  3:37               ` Dan Williams
  2019-12-11  4:27                 ` Tao Xu
  0 siblings, 1 reply; 13+ messages in thread
From: Dan Williams @ 2019-12-11  3:37 UTC (permalink / raw)
  To: Tao Xu
  Cc: Rafael J. Wysocki, Rafael Wysocki, Len Brown, Greg Kroah-Hartman,
	Dave Hansen, ACPI Devel Maling List, Linux Kernel Mailing List

On Tue, Dec 10, 2019 at 7:05 PM Tao Xu <tao3.xu@intel.com> 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 <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.
>
> 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 <keith.busch@intel.com>
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 <keith.busch@intel.com>
Description:
                The cache write policy: 0 for write-back, 1 for write-through,
                other or unknown.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy
  2019-12-11  3:37               ` Dan Williams
@ 2019-12-11  4:27                 ` Tao Xu
  0 siblings, 0 replies; 13+ messages in thread
From: Tao Xu @ 2019-12-11  4:27 UTC (permalink / raw)
  To: Dan Williams
  Cc: Rafael J. Wysocki, Rafael Wysocki, Len Brown, Greg Kroah-Hartman,
	Dave Hansen, ACPI Devel Maling List, Linux Kernel Mailing List

On 12/11/2019 11:37 AM, Dan Williams wrote:
> On Tue, Dec 10, 2019 at 7:05 PM Tao Xu <tao3.xu@intel.com> 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 <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.
>>
>> 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 <keith.busch@intel.com>
> 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 <keith.busch@intel.com>
> Description:
>                  The cache write policy: 0 for write-back, 1 for write-through,
>                  other or unknown.
> 

I understand. Thank you for your explanation.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-12-11  4:27 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-12-11  3:04             ` Tao Xu
2019-12-11  3:37               ` Dan Williams
2019-12-11  4:27                 ` Tao Xu

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).