All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <sudeep.holla@arm.com>
Cc: <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<atishp@atishpatra.org>, <atishp@rivosinc.com>,
	<vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
	<wangqing@vivo.com>, <robh+dt@kernel.org>, <rafael@kernel.org>,
	<ionela.voinescu@arm.com>, <pierre.gondois@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <gshan@redhat.com>,
	<Valentina.FernandezAlanis@microchip.com>
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo
Date: Fri, 1 Jul 2022 14:47:16 +0000	[thread overview]
Message-ID: <64272301-7fd5-c996-217d-2b83e85fc1b7@microchip.com> (raw)
In-Reply-To: <20220701111156.dqmdrj2hzjadojz2@bogus>

On 01/07/2022 12:11, Sudeep Holla wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Jun 30, 2022 at 10:07:49PM +0000, Conor.Dooley@microchip.com wrote:
>>
>>
>> On 30/06/2022 21:21, Sudeep Holla wrote:
>>> On Thu, Jun 30, 2022 at 08:13:55PM +0000, Conor.Dooley@microchip.com wrote:
>>>>
>>>> I didn't have the time to go digging into things, but the following
>>>> macro looked odd:
>>>> #define per_cpu_cacheinfo_idx(cpu, idx)            \
>>>>                             (per_cpu_cacheinfo(cpu) + (idx))
>>>> Maybe it is just badly named, but is this getting the per_cpu_cacheinfo
>>>> and then incrementing intentionally, or is it meant to get the
>>>> per_cpu_cacheinfo of cpu + idx?
>>>
>>> OK, basically per_cpu_cacheinfo(cpu) get the information for a cpu
>>> while per_cpu_cacheinfo_idx(cpu, idx) will fetch the information for a
>>> given cpu and given index within the cpu. So we are incrementing the
>>> pointer by the index. These work just fine on arm64 platform.
>>
>> Right, that's what I figured but wanted to be sure.
>>
> 
> OK
> 
>>>
>>> Not sure if compiler is optimising something as I still can't understand
>>> how we can end up with valid llc but fw_token as NULL.
>> See idk about that. The following fails to boot.
>> index 167abfa6f37d..9d45c37fb004 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
> 
> Did you hit this ?

Ah I forgot to remove this, I had added it (since I knew a return value
of false was correct) but it was still failing to boot. It was my step
prior to adding the if(!llc...

> 
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -74,8 +76,12 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>> +       if (!llc_x || !llc_y){
>> +               printk("llc was null\n");
> 
> Or this ?

This printk never prints out.

> 
>> +               return false;
>> +       }
>>
>> -       return cache_leaves_are_shared(llc_x, llc_y);
>> +       return false; //cache_leaves_are_shared(llc_x, llc_y);
> 
> Even the above change fails to boot ? Coz you are always returning false here
> too.

Correct, fails to boot.

> 
>>   }
>>
>>   #ifdef CONFIG_OF
>>
>> and this boots:
>>
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index 167abfa6f37d..01900908fe31 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -75,7 +77,7 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>>
> 
> You are just missing the checks for llc_x and llc_y and it works which
> means llc_x and llc_y is where things are going wrong.
> 

Sounds about right to me.


WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <sudeep.holla@arm.com>
Cc: <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<atishp@atishpatra.org>, <atishp@rivosinc.com>,
	<vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
	<wangqing@vivo.com>, <robh+dt@kernel.org>, <rafael@kernel.org>,
	<ionela.voinescu@arm.com>, <pierre.gondois@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <gshan@redhat.com>,
	<Valentina.FernandezAlanis@microchip.com>
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo
Date: Fri, 1 Jul 2022 14:47:16 +0000	[thread overview]
Message-ID: <64272301-7fd5-c996-217d-2b83e85fc1b7@microchip.com> (raw)
In-Reply-To: <20220701111156.dqmdrj2hzjadojz2@bogus>

On 01/07/2022 12:11, Sudeep Holla wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Jun 30, 2022 at 10:07:49PM +0000, Conor.Dooley@microchip.com wrote:
>>
>>
>> On 30/06/2022 21:21, Sudeep Holla wrote:
>>> On Thu, Jun 30, 2022 at 08:13:55PM +0000, Conor.Dooley@microchip.com wrote:
>>>>
>>>> I didn't have the time to go digging into things, but the following
>>>> macro looked odd:
>>>> #define per_cpu_cacheinfo_idx(cpu, idx)            \
>>>>                             (per_cpu_cacheinfo(cpu) + (idx))
>>>> Maybe it is just badly named, but is this getting the per_cpu_cacheinfo
>>>> and then incrementing intentionally, or is it meant to get the
>>>> per_cpu_cacheinfo of cpu + idx?
>>>
>>> OK, basically per_cpu_cacheinfo(cpu) get the information for a cpu
>>> while per_cpu_cacheinfo_idx(cpu, idx) will fetch the information for a
>>> given cpu and given index within the cpu. So we are incrementing the
>>> pointer by the index. These work just fine on arm64 platform.
>>
>> Right, that's what I figured but wanted to be sure.
>>
> 
> OK
> 
>>>
>>> Not sure if compiler is optimising something as I still can't understand
>>> how we can end up with valid llc but fw_token as NULL.
>> See idk about that. The following fails to boot.
>> index 167abfa6f37d..9d45c37fb004 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
> 
> Did you hit this ?

Ah I forgot to remove this, I had added it (since I knew a return value
of false was correct) but it was still failing to boot. It was my step
prior to adding the if(!llc...

> 
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -74,8 +76,12 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>> +       if (!llc_x || !llc_y){
>> +               printk("llc was null\n");
> 
> Or this ?

This printk never prints out.

> 
>> +               return false;
>> +       }
>>
>> -       return cache_leaves_are_shared(llc_x, llc_y);
>> +       return false; //cache_leaves_are_shared(llc_x, llc_y);
> 
> Even the above change fails to boot ? Coz you are always returning false here
> too.

Correct, fails to boot.

> 
>>   }
>>
>>   #ifdef CONFIG_OF
>>
>> and this boots:
>>
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index 167abfa6f37d..01900908fe31 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -75,7 +77,7 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>>
> 
> You are just missing the checks for llc_x and llc_y and it works which
> means llc_x and llc_y is where things are going wrong.
> 

Sounds about right to me.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <sudeep.holla@arm.com>
Cc: <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<atishp@atishpatra.org>, <atishp@rivosinc.com>,
	<vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
	<wangqing@vivo.com>, <robh+dt@kernel.org>, <rafael@kernel.org>,
	<ionela.voinescu@arm.com>, <pierre.gondois@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <gshan@redhat.com>,
	<Valentina.FernandezAlanis@microchip.com>
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo
Date: Fri, 1 Jul 2022 14:47:16 +0000	[thread overview]
Message-ID: <64272301-7fd5-c996-217d-2b83e85fc1b7@microchip.com> (raw)
In-Reply-To: <20220701111156.dqmdrj2hzjadojz2@bogus>

On 01/07/2022 12:11, Sudeep Holla wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Jun 30, 2022 at 10:07:49PM +0000, Conor.Dooley@microchip.com wrote:
>>
>>
>> On 30/06/2022 21:21, Sudeep Holla wrote:
>>> On Thu, Jun 30, 2022 at 08:13:55PM +0000, Conor.Dooley@microchip.com wrote:
>>>>
>>>> I didn't have the time to go digging into things, but the following
>>>> macro looked odd:
>>>> #define per_cpu_cacheinfo_idx(cpu, idx)            \
>>>>                             (per_cpu_cacheinfo(cpu) + (idx))
>>>> Maybe it is just badly named, but is this getting the per_cpu_cacheinfo
>>>> and then incrementing intentionally, or is it meant to get the
>>>> per_cpu_cacheinfo of cpu + idx?
>>>
>>> OK, basically per_cpu_cacheinfo(cpu) get the information for a cpu
>>> while per_cpu_cacheinfo_idx(cpu, idx) will fetch the information for a
>>> given cpu and given index within the cpu. So we are incrementing the
>>> pointer by the index. These work just fine on arm64 platform.
>>
>> Right, that's what I figured but wanted to be sure.
>>
> 
> OK
> 
>>>
>>> Not sure if compiler is optimising something as I still can't understand
>>> how we can end up with valid llc but fw_token as NULL.
>> See idk about that. The following fails to boot.
>> index 167abfa6f37d..9d45c37fb004 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
> 
> Did you hit this ?

Ah I forgot to remove this, I had added it (since I knew a return value
of false was correct) but it was still failing to boot. It was my step
prior to adding the if(!llc...

> 
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -74,8 +76,12 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>> +       if (!llc_x || !llc_y){
>> +               printk("llc was null\n");
> 
> Or this ?

This printk never prints out.

> 
>> +               return false;
>> +       }
>>
>> -       return cache_leaves_are_shared(llc_x, llc_y);
>> +       return false; //cache_leaves_are_shared(llc_x, llc_y);
> 
> Even the above change fails to boot ? Coz you are always returning false here
> too.

Correct, fails to boot.

> 
>>   }
>>
>>   #ifdef CONFIG_OF
>>
>> and this boots:
>>
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index 167abfa6f37d..01900908fe31 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -36,6 +36,8 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>                                             struct cacheinfo *sib_leaf)
>>   {
>> +       if (!this_leaf || !sib_leaf)
>> +               return false;
>>          /*
>>           * For non DT/ACPI systems, assume unique level 1 caches,
>>           * system-wide shared caches for all other levels. This will be used
>> @@ -75,7 +77,7 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y)
>>          llc_x = per_cpu_cacheinfo_idx(cpu_x, cache_leaves(cpu_x) - 1);
>>          llc_y = per_cpu_cacheinfo_idx(cpu_y, cache_leaves(cpu_y) - 1);
>>
> 
> You are just missing the checks for llc_x and llc_y and it works which
> means llc_x and llc_y is where things are going wrong.
> 

Sounds about right to me.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-01 14:47 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 16:50 [PATCH v5 00/19] arch_topology: Updates to add socket support and fix cluster ids Sudeep Holla
2022-06-27 16:50 ` Sudeep Holla
2022-06-27 16:50 ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 01/19] ACPI: PPTT: Use table offset as fw_token instead of virtual address Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 02/19] cacheinfo: Use of_cpu_device_node_get instead cpu_dev->of_node Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 03/19] cacheinfo: Add helper to access any cache index for a given CPU Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 04/19] cacheinfo: Move cache_leaves_are_shared out of CONFIG_OF Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 05/19] cacheinfo: Add support to check if last level cache(LLC) is valid or shared Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 06/19] cacheinfo: Allow early detection and population of cache attributes Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 07/19] cacheinfo: Use cache identifiers to check if the caches are shared if available Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 08/19] arch_topology: Add support to parse and detect cache attributes Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-29 17:49   ` Conor.Dooley
2022-06-29 17:49     ` Conor.Dooley
2022-06-29 17:49     ` Conor.Dooley
2022-06-29 18:18     ` Conor.Dooley
2022-06-29 18:18       ` Conor.Dooley
2022-06-29 18:18       ` Conor.Dooley
2022-06-29 18:33       ` Sudeep Holla
2022-06-29 18:33         ` Sudeep Holla
2022-06-29 18:33         ` Sudeep Holla
2022-06-29 18:42       ` Sudeep Holla
2022-06-29 18:42         ` Sudeep Holla
2022-06-29 18:42         ` Sudeep Holla
2022-06-29 19:39         ` Conor.Dooley
2022-06-29 19:39           ` Conor.Dooley
2022-06-29 19:39           ` Conor.Dooley
2022-06-29 19:54           ` Sudeep Holla
2022-06-29 19:54             ` Sudeep Holla
2022-06-29 19:54             ` Sudeep Holla
2022-06-29 20:32             ` Conor.Dooley
2022-06-29 20:32               ` Conor.Dooley
2022-06-29 20:32               ` Conor.Dooley
2022-06-29 23:25               ` Conor.Dooley
2022-06-29 23:25                 ` Conor.Dooley
2022-06-29 23:25                 ` Conor.Dooley
2022-06-30 10:39                 ` Sudeep Holla
2022-06-30 10:39                   ` Sudeep Holla
2022-06-30 10:39                   ` Sudeep Holla
2022-06-30 16:37                   ` Conor.Dooley
2022-06-30 16:37                     ` Conor.Dooley
2022-06-30 16:37                     ` Conor.Dooley
2022-06-30 17:35                     ` Sudeep Holla
2022-06-30 17:35                       ` Sudeep Holla
2022-06-30 17:35                       ` Sudeep Holla
2022-06-30 19:20                       ` Conor.Dooley
2022-06-30 19:20                         ` Conor.Dooley
2022-06-30 19:20                         ` Conor.Dooley
2022-06-30 20:07                         ` Sudeep Holla
2022-06-30 20:07                           ` Sudeep Holla
2022-06-30 20:07                           ` Sudeep Holla
2022-06-30 20:13                           ` Conor.Dooley
2022-06-30 20:13                             ` Conor.Dooley
2022-06-30 20:13                             ` Conor.Dooley
2022-06-30 20:21                             ` Sudeep Holla
2022-06-30 20:21                               ` Sudeep Holla
2022-06-30 20:21                               ` Sudeep Holla
2022-06-30 22:07                               ` Conor.Dooley
2022-06-30 22:07                                 ` Conor.Dooley
2022-06-30 22:07                                 ` Conor.Dooley
2022-07-01 11:11                                 ` Sudeep Holla
2022-07-01 11:11                                   ` Sudeep Holla
2022-07-01 11:11                                   ` Sudeep Holla
2022-07-01 14:47                                   ` Conor.Dooley [this message]
2022-07-01 14:47                                     ` Conor.Dooley
2022-07-01 14:47                                     ` Conor.Dooley
2022-06-29 18:47       ` Sudeep Holla
2022-06-29 18:47         ` Sudeep Holla
2022-06-29 18:47         ` Sudeep Holla
2022-06-29 18:56         ` Conor.Dooley
2022-06-29 18:56           ` Conor.Dooley
2022-06-29 18:56           ` Conor.Dooley
2022-06-29 19:12           ` Sudeep Holla
2022-06-29 19:12             ` Sudeep Holla
2022-06-29 19:12             ` Sudeep Holla
2022-06-29 19:25             ` Conor.Dooley
2022-06-29 19:25               ` Conor.Dooley
2022-06-29 19:25               ` Conor.Dooley
2022-06-29 19:43               ` Sudeep Holla
2022-06-29 19:43                 ` Sudeep Holla
2022-06-29 19:43                 ` Sudeep Holla
2022-06-29 19:52                 ` Conor.Dooley
2022-06-29 19:52                   ` Conor.Dooley
2022-06-29 19:52                   ` Conor.Dooley
2022-06-29 18:29     ` Sudeep Holla
2022-06-29 18:29       ` Sudeep Holla
2022-06-29 18:29       ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 10/19] arm64: topology: Remove redundant setting of llc_id in CPU topology Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 11/19] arch_topology: Drop LLC identifier stash from the " Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 12/19] arch_topology: Set thread sibling cpumask only within the cluster Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 13/19] arch_topology: Check for non-negative value rather than -1 for IDs validity Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 14/19] arch_topology: Avoid parsing through all the CPUs once a outlier CPU is found Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 15/19] arch_topology: Don't set cluster identifier as physical package identifier Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 16/19] arch_topology: Limit span of cpu_clustergroup_mask() Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-28 10:28   ` Vincent Guittot
2022-06-28 10:28     ` Vincent Guittot
2022-06-28 10:28     ` Vincent Guittot
2022-06-27 16:50 ` [PATCH v5 17/19] arch_topology: Set cluster identifier in each core/thread from /cpu-map Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 18/19] arch_topology: Add support for parsing sockets in /cpu-map Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50 ` [PATCH v5 19/19] arch_topology: Warn that topology for nested clusters is not supported Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-27 16:50   ` Sudeep Holla
2022-06-29 13:06 ` [PATCH] ACPI: Remove the unused find_acpi_cpu_cache_topology() Sudeep Holla
2022-06-29 13:06   ` Sudeep Holla
2022-06-29 13:06   ` Sudeep Holla
2022-06-29 13:50   ` Rafael J. Wysocki
2022-06-29 13:50     ` Rafael J. Wysocki
2022-06-29 13:50     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64272301-7fd5-c996-217d-2b83e85fc1b7@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=Valentina.FernandezAlanis@microchip.com \
    --cc=atishp@atishpatra.org \
    --cc=atishp@rivosinc.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshan@redhat.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=wangqing@vivo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.