AW: parallel load of modules on an ARM multicore
EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31)
external.Peter.Waechtler at de.bosch.com
Thu Jun 23 11:20:39 EDT 2011
No, you didn't say that, but the patch ;)
@@ -114,7 +114,8 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
/* check for possible thread migration */
if (!cpumask_empty(mm_cpumask(next)) &&
- !cpumask_test_cpu(cpu, mm_cpumask(next)))
+ (cache_ops_need_broadcast() ||
+ !cpumask_test_cpu(cpu, mm_cpumask(next))))
On ARM11MPcore cache_ops_need_broadcast() returns true -
with that, anytime the thread migrates the icache is flushed?
Mit freundlichen Grüßen / Best regards
> -----Ursprüngliche Nachricht-----
> Von: Catalin Marinas [mailto:catalin.marinas at gmail.com] Im
> Auftrag von Catalin Marinas
> Gesendet: Donnerstag, 23. Juni 2011 16:52
> An: EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31)
> Cc: linux-arm-kernel at lists.infradead.org
> Betreff: Re: parallel load of modules on an ARM multicore
> On Thu, Jun 23, 2011 at 04:39:01PM +0200, EXTERNAL Waechtler
> Peter (Fa. TCP, CM-AI/PJ-CF31) wrote:
> > it's interesting that you almost agree with me.
> > But isn't it really expensive to flush the icache on switch_mm?
> > Is that meant as a test to see if the problem goes away?
> Who said anything about flushing the icache on switch_mm()? My patch
> doesn't do this, it actually reduces the amount of cache flushing on
> > Wouldn't it suffice to get_cpu/put_cpu to disable preemption while
> > load_module() works?
> It may work, just give it a try.
> > I think the other way will cause trouble: the module is loaded on
> > cpu0 for example, preempted, woken up on cpu1 with a stale icache
> > line not holding the "newly loaded code" and running mod->init peng!
> > Nobody told cpu1 to revalidate it's icache.
> > Don't know if this is possible though.
> That's possible as well if the pages allocated for the module
> code have
> been previously used for other code.
> To resolve the stale I-cache lines, you would have to broadcast the
> cache maintenance to all the CPUs. For the D-cache we could trick the
> CPU via some reading to force the dirty cache lines migration
> but that's
> not possible for the I-cache.
> > The data of the module won't get through the icache anyway.
> No but the module is copied into the new allocated space via the
> D-cache. This needs to be flushed so that the I-cache would get the
> right instructions.
> > AFAIK we are not able to reproduce quickly and it will take some
> > time before I can try...
> OK, just let us know how it goes.
More information about the linux-arm-kernel