[PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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,
>   };
>   
>   /**
> 

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Greg KH]

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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Rafael J. Wysocki]

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,
>  };
>
>  /**

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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,
>>   };
>>
>>   /**

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Rafael J. Wysocki]

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.

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Rafael J. Wysocki]

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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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.

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Dan Williams]

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.

Re: [PATCH] ACPI/HMAT: Fix the parsing of Cache Associativity and Write Policy

[Tao Xu]

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.