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
Attachment:
signature.asc
Description: OpenPGP digital signature
