On Sat, 2014-05-03 at 10:32 +0200, Nicholas Mc Guire wrote: > On Fri, 02 May 2014, Mike Galbraith wrote: > > > On Fri, 2014-05-02 at 15:39 +0400, Pavel Vasilyev wrote: > > > 02.05.2014 15:12, Mike Galbraith ??????????: > > > > The following patches are fixes that fell out of testing rt1. Patches > > > > 1-4 are intended to be folded into existing patches, 5-6 are > > > > replacements. > > > > > > > > fold: > > > > 1/6 - preempt-lazy-support.patch > > > > 2/6 - x86-preempt-lazy.patch > > > > 3/6 - hotplug-light-get-online-cpus.patch > > > > 4/6 - stomp-machine-raw-lock.patch > > > > > > > > replace: > > > > 5/6 - (prep) > > > > 6/6 - stomp-machine-deal-clever-with-stopper-lock.patch > > > > > > > > drop: (buggy - calls migrate_disable() _after_ maybe blocking) > > > > migrate_disable-pushd-down-in-atomic_dec_and_spin_lo.patch > > > > > > > Why would calling migrate_disable be buggy after blocking ? > at that point any per cpu data is not yet being accessed so its perfectly fine > to > > lock->block > -> migrate > -> unblock->lock > -> migrate_disable on a new CPU > -> access per_cpu object > -> migrate_enable > -> unlock > > what problems would there be ? You tell me. Why do we bother at all if it's ok to migrate with a lock in your pocket, or the CPU can go away on you while you're acquiring? If this is in fact safe, you should be able to move each and every migrate_disable() to post acquisition. I have a virtual nickle that says your box will have a severe allergic reaction to such a patch. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
