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:
- No locking at all is required on systems where the b.L switcher is not configured.
ACK
- 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