On Thu, 26 Feb 2015, Daniel Thompson wrote: > On Thu, 2015-02-26 at 15:31 -0500, Nicolas Pitre wrote: > > On Tue, 3 Feb 2015, Daniel Thompson wrote: > > > > > Currently gic_raise_softirq() is locked using upon irq_controller_lock. > > > This lock is primarily used to make register read-modify-write sequences > > > atomic but gic_raise_softirq() uses it instead to ensure that the > > > big.LITTLE migration logic can figure out when it is safe to migrate > > > interrupts between physical cores. > > > > > > This is sub-optimal in closely related ways: > > > > > > 1. No locking at all is required on systems where the b.L switcher is > > > not configured. > > > > ACK > > > > > 2. Finer grain locking can be used on systems where the b.L switcher is > > > present. > > > > NAK > > > > Consider this sequence: > > > > CPU 1 CPU 2 > > ----- ----- > > gic_raise_softirq() gic_migrate_target() > > bl_migration_lock() [OK] > > [...] [...] > > map |= gic_cpu_map[cpu]; bl_migration_lock() [contended] > > bl_migration_unlock(flags); bl_migration_lock() [OK] > > gic_cpu_map[cpu] = 1 << new_cpu_id; > > bl_migration_unlock(flags); > > [...] > > (migrate pending IPI from old CPU) > > writel_relaxed(map to GIC_DIST_SOFTINT); > > Isn't this solved inside gic_raise_softirq? How can the writel_relaxed() > escape from the critical section and happen at the end of the sequence?
Hmmm... blah. OK I obviously can't read today. The patch is fine of course. > > Oh, and a minor nit: > > > > > + * This lock is used by the big.LITTLE migration code to ensure no IPIs > > > + * can be pended on the old core after the map has been updated. > > > + */ > > > +#ifdef CONFIG_BL_SWITCHER > > > +static DEFINE_RAW_SPINLOCK(cpu_map_migration_lock); > > > + > > > +static inline void bl_migration_lock(unsigned long *flags) > > > > Please name it gic_migration_lock. "bl_migration_lock" is a bit too > > generic in this context. > > I'll change this. Good. You may add my ACK. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
