From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] kvm: Drop obsolete cpu_get/put in make_all_cpus_request
Date: Tue, 21 Jul 2009 20:37:09 -0300
Message-ID: <20090721233709.GA11373@amt.cnet>
References: <4A643924.6060908@siemens.com> <20090721000054.GB15189@amt.cnet> <4A657B28.5030006@siemens.com> <20090721171025.GA6959@amt.cnet> <4A664F54.3080507@web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm-devel <kvm@vger.kernel.org>
To: Jan Kiszka <jan.kiszka@web.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.redhat.com ([66.187.237.31]:35254 "EHLO mx2.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755551AbZGUXhs (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 21 Jul 2009 19:37:48 -0400
Content-Disposition: inline
In-Reply-To: <4A664F54.3080507@web.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.