Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1203392 > unrolled thread

[PATCH 4.1 013/123] MIPS: c-r4k: Fix cache flushing for MT cores

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 4.1 013/123] MIPS: c-r4k: Fix cache flushing for MT cores Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-08-09 00:20 +0200
    Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2015-08-10 20:40 +0200
      Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2015-08-10 21:00 +0200
        Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2015-08-10 21:20 +0200
          Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2015-08-10 21:20 +0200
            Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2015-08-10 21:30 +0200
          Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores Markos Chandras <markos.chandras@imgtec.com> - 2015-08-10 21:20 +0200

#1203392 — [PATCH 4.1 013/123] MIPS: c-r4k: Fix cache flushing for MT cores

4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Markos Chandras <markos.chandras@imgtec.com>

commit cccf34e9411c41b0cbfb41980fe55fc8e7c98fd2 upstream.

MT_SMP is not the only SMP option for MT cores. The MT_SMP option
allows more than one VPE per core to appear as a secondary CPU in the
system. Because of how CM works, it propagates the address-based
cache ops to the secondary cores but not the index-based ones.
Because of that, the code does not use IPIs to flush the L1 caches on
secondary cores because the CM would have done that already. However,
the CM functionality is independent of the type of SMP kernel so even in
non-MT kernels, IPIs are not necessary. As a result of which, we change
the conditional to depend on the CM presence. Moreover, since VPEs on
the same core share the same L1 caches, there is no need to send an
IPI on all of them so we calculate a suitable cpumask with only one
VPE per core.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10654/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/include/asm/smp.h |    1 +
 arch/mips/kernel/smp.c      |   44 +++++++++++++++++++++++++++++++++++++++++++-
 arch/mips/mm/c-r4k.c        |   14 +++++++++++---
 3 files changed, 55 insertions(+), 4 deletions(-)

--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -23,6 +23,7 @@
 extern int smp_num_siblings;
 extern cpumask_t cpu_sibling_map[];
 extern cpumask_t cpu_core_map[];
+extern cpumask_t cpu_foreign_map;
 
 #define raw_smp_processor_id() (current_thread_info()->cpu)
 
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -63,6 +63,13 @@ EXPORT_SYMBOL(cpu_sibling_map);
 cpumask_t cpu_core_map[NR_CPUS] __read_mostly;
 EXPORT_SYMBOL(cpu_core_map);
 
+/*
+ * A logcal cpu mask containing only one VPE per core to
+ * reduce the number of IPIs on large MT systems.
+ */
+cpumask_t cpu_foreign_map __read_mostly;
+EXPORT_SYMBOL(cpu_foreign_map);
+
 /* representing cpus for which sibling maps can be computed */
 static cpumask_t cpu_sibling_setup_map;
 
@@ -103,6 +110,29 @@ static inline void set_cpu_core_map(int
 	}
 }
 
+/*
+ * Calculate a new cpu_foreign_map mask whenever a
+ * new cpu appears or disappears.
+ */
+static inline void calculate_cpu_foreign_map(void)
+{
+	int i, k, core_present;
+	cpumask_t temp_foreign_map;
+
+	/* Re-calculate the mask */
+	for_each_online_cpu(i) {
+		core_present = 0;
+		for_each_cpu(k, &temp_foreign_map)
+			if (cpu_data[i].package == cpu_data[k].package &&
+			    cpu_data[i].core == cpu_data[k].core)
+				core_present = 1;
+		if (!core_present)
+			cpumask_set_cpu(i, &temp_foreign_map);
+	}
+
+	cpumask_copy(&cpu_foreign_map, &temp_foreign_map);
+}
+
 struct plat_smp_ops *mp_ops;
 EXPORT_SYMBOL(mp_ops);
 
@@ -146,6 +176,8 @@ asmlinkage void start_secondary(void)
 	set_cpu_sibling_map(cpu);
 	set_cpu_core_map(cpu);
 
+	calculate_cpu_foreign_map();
+
 	cpumask_set_cpu(cpu, &cpu_callin_map);
 
 	synchronise_count_slave(cpu);
@@ -173,9 +205,18 @@ void __irq_entry smp_call_function_inter
 static void stop_this_cpu(void *dummy)
 {
 	/*
-	 * Remove this CPU:
+	 * Remove this CPU. Be a bit slow here and
+	 * set the bits for every online CPU so we don't miss
+	 * any IPI whilst taking this VPE down.
 	 */
+
+	cpumask_copy(&cpu_foreign_map, cpu_online_mask);
+
+	/* Make it visible to every other CPU */
+	smp_mb();
+
 	set_cpu_online(smp_processor_id(), false);
+	calculate_cpu_foreign_map();
 	local_irq_disable();
 	while (1);
 }
@@ -197,6 +238,7 @@ void __init smp_prepare_cpus(unsigned in
 	mp_ops->prepare_cpus(max_cpus);
 	set_cpu_sibling_map(0);
 	set_cpu_core_map(0);
+	calculate_cpu_foreign_map();
 #ifndef CONFIG_HOTPLUG_CPU
 	init_cpu_present(cpu_possible_mask);
 #endif
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -37,6 +37,7 @@
 #include <asm/cacheflush.h> /* for run_uncached() */
 #include <asm/traps.h>
 #include <asm/dma-coherence.h>
+#include <asm/mips-cm.h>
 
 /*
  * Special Variant of smp_call_function for use by cache functions:
@@ -51,9 +52,16 @@ static inline void r4k_on_each_cpu(void
 {
 	preempt_disable();
 
-#ifndef CONFIG_MIPS_MT_SMP
-	smp_call_function(func, info, 1);
-#endif
+	/*
+	 * The Coherent Manager propagates address-based cache ops to other
+	 * cores but not index-based ops. However, r4k_on_each_cpu is used
+	 * in both cases so there is no easy way to tell what kind of op is
+	 * executed to the other cores. The best we can probably do is
+	 * to restrict that call when a CM is not present because both
+	 * CM-based SMP protocols (CMP & CPS) restrict index-based cache ops.
+	 */
+	if (!mips_cm_present())
+		smp_call_function_many(&cpu_foreign_map, func, info, 1);
 	func(info);
 	preempt_enable();
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1204476 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote:
> 4.1-stable review patch.  If anyone has any objections, please let me know.
>
>
Yes, I have objection. Please look into excepts from my mail exchange 
with Markos:

> On 06/25/2015 03:59 AM, Markos Chandras wrote:
>
>> @@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info)
>>   {
>>   	preempt_disable();
>>   
>> -#ifndef CONFIG_MIPS_MT_SMP
>> -	smp_call_function(func, info, 1);
>> -#endif
>> +	if (config_enabled(CONFIG_SMP))
>> +		smp_call_function_many(&cpu_foreign_map, func, info, 1);
>>   	func(info);
>>   	preempt_enable();
>>   }
>
> You can NOT do this because r4k_on_each_cpu() is still used for 
> non-MIPS/IMG processors for SAFE INDEX cache flushes - 
> cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment).
>
>
> And a little explanation and history:
>
> The function r4k_on_each_cpu() can NOT be used simultaneously for 
> index cacheops and address cacheops because both have a different 
> rules in applying in other cores and that is different in inter-core 
> HW blocks of various vendors. CM propogates address cacheops from 
> core-to-core (no IPI calls are needed) but another vendors may do not 
> - this is indicated by CONFIG_MIPS_MT_SMP (and a dropped now 
> CONFIG_MIPS_MT_SMTC).
>
> Unfortunately, before 2.6.35.9 this function was used for index 
> cacheops too in any kernel and that is WRONG, at least for CM-based 
> systems.
> So, I splitted index and address cacheops and wrote a functions 
> r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 
> and it finally made a way to dev-linux-mti-3.6. This is a famous patch 
> named:
>
>     MIPS: Cache flush functions are reworked.
>
>     This patch is a preparation for EVA support in kernel.
>
>     However, it also fixes a bug then index cacheop was not ran
>     on multiple CPUs with unsafe index cacheops (flush_cache_vmap,
>     flush_icache_range, flush_cache_range, __flush_cache_all).
>
>     Additionally, it optimizes a usage of index and address cacheops for
>     address range flushes depending from address range size.
>
>     Because of that reasons it is a separate patch from EVA support.
>
>     Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>     Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
>     (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7)
>

(history is skipped)

Note: the replacement of

     if (config_enabled(CONFIG_SMP))

to
if (!mips_cm_present())

doesn't solve a problem - in CM-based environment the index cache ops 
MUST be delivered to other core via IPI.

- Leonid.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204482 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote:
> >4.1-stable review patch.  If anyone has any objections, please let me know.
> >
> >
> Yes, I have objection. Please look into excepts from my mail exchange with
> Markos:
> 
> >On 06/25/2015 03:59 AM, Markos Chandras wrote:
> >
> >>@@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info)
> >>  {
> >>  	preempt_disable();
> >>-#ifndef CONFIG_MIPS_MT_SMP
> >>-	smp_call_function(func, info, 1);
> >>-#endif
> >>+	if (config_enabled(CONFIG_SMP))
> >>+		smp_call_function_many(&cpu_foreign_map, func, info, 1);
> >>  	func(info);
> >>  	preempt_enable();
> >>  }
> >
> >You can NOT do this because r4k_on_each_cpu() is still used for
> >non-MIPS/IMG processors for SAFE INDEX cache flushes -
> >cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment).
> >
> >
> >And a little explanation and history:
> >
> >The function r4k_on_each_cpu() can NOT be used simultaneously for index
> >cacheops and address cacheops because both have a different rules in
> >applying in other cores and that is different in inter-core HW blocks of
> >various vendors. CM propogates address cacheops from core-to-core (no IPI
> >calls are needed) but another vendors may do not - this is indicated by
> >CONFIG_MIPS_MT_SMP (and a dropped now CONFIG_MIPS_MT_SMTC).
> >
> >Unfortunately, before 2.6.35.9 this function was used for index cacheops
> >too in any kernel and that is WRONG, at least for CM-based systems.
> >So, I splitted index and address cacheops and wrote a functions
> >r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 and
> >it finally made a way to dev-linux-mti-3.6. This is a famous patch named:
> >
> >    MIPS: Cache flush functions are reworked.
> >
> >    This patch is a preparation for EVA support in kernel.
> >
> >    However, it also fixes a bug then index cacheop was not ran
> >    on multiple CPUs with unsafe index cacheops (flush_cache_vmap,
> >    flush_icache_range, flush_cache_range, __flush_cache_all).
> >
> >    Additionally, it optimizes a usage of index and address cacheops for
> >    address range flushes depending from address range size.
> >
> >    Because of that reasons it is a separate patch from EVA support.
> >
> >    Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> >    Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
> >    (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7)
> >
> 
> (history is skipped)
> 
> Note: the replacement of
> 
>     if (config_enabled(CONFIG_SMP))
> 
> to
> if (!mips_cm_present())
> 
> doesn't solve a problem - in CM-based environment the index cache ops MUST
> be delivered to other core via IPI.

So, this is broken in Linus's tree too?  Or is it fixed there, and if
so, what is the git commit id?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204500 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>
> So, this is broken in Linus's tree too?

Yes.

>    Or is it fixed there, and if
> so, what is the git commit id?

There is no an accepted fix. My old patch is in

https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12

It was a precursor for my EVA set of patches since2.6.35.9 but was never 
accepted and was lost during redesign of EVA by Markos.

- Leonid.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204501 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> >On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> >>
> >So, this is broken in Linus's tree too?
> 
> Yes.

Great, as long as I am consistent, that's all that I care about :)

> >   Or is it fixed there, and if
> >so, what is the git commit id?
> 
> There is no an accepted fix. My old patch is in
> 
> https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12
> 
> It was a precursor for my EVA set of patches since2.6.35.9 but was never
> accepted and was lost during redesign of EVA by Markos.

Please work with the mips developers to get this accepted, and mark it
for -stable as well.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204511 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On 08/10/2015 12:19 PM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
>> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
>>> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>> So, this is broken in Linus's tree too?
>> Yes.
> Great, as long as I am consistent, that's all that I care about :)
>
>

You asked "If anyone has any objections, please let me know" and I did that.

- Leonid.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204502 — Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> > On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> >>
> > So, this is broken in Linus's tree too?
> 
> Yes.
> 
> >    Or is it fixed there, and if
> > so, what is the git commit id?
> 
> There is no an accepted fix. My old patch is in
> 
> https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12
> 
> It was a precursor for my EVA set of patches since2.6.35.9 but was never 
> accepted and was lost during redesign of EVA by Markos.
> 
> - Leonid.
> 

I hope you realize that blocking this patch from the stable trees does not
actually fix the problem. The patch may not be perfect but it's better than what
we had before.

-- 
markos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web