On Wed, Jul 22, 2009 at 01:29:24AM +0200, Jan Kiszka wrote: > Marcelo Tosatti wrote: > > On Tue, Jul 21, 2009 at 10:24:08AM +0200, Jan Kiszka wrote: > >> Marcelo Tosatti wrote: > >>> Jan, > >>> > >>> This was suggested but we thought it might be safer to keep the > >>> get_cpu/put_cpu pair in case -rt kernels require it (which might be > >>> bullshit, but nobody verified). > >> -rt stumbles over both patterns (that's why I stumbled over it in the > >> first place: get_cpu disables preemption, but spin_lock is a sleeping > >> lock under -rt) and actually requires requests_lock to become > >> raw_spinlock_t. Reordering get_cpu and spin_lock would be another > >> option, but not really a gain for both scenarios. > > > > I see. > > > >> So unless there is a way to make the whole critical section preemptible > >> (thus migration-agnostic), I think we can micro-optimize it like this. > > > > Can't you switch requests_lock to be raw_spinlock_t then? (or whatever > > is necessary to make it -rt compatible). > > > > raw_spinlock_t over -rt is not comparable to raw_spinlock_t over > mainline. So I'm currently carrying a local patch with > > #ifdef CONFIG_PREEMPT_RT > raw_spinlock_t some_lock; > #else > spinlock_t some_lock; > #endif > > for all locks that need it (there are three ATM). > > That said, I'm suspecting there are more problems with kvm over -rt > right now. I'm seeing significant latency peeks on the host. Still > investigating, though. > > However I don't think we should bother too much about -rt compliance in > mainline unless the diff is trivial and basically irrelevant for the > common non-rt cases. > > Jan OK then, applied. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
