From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH] kvm: Drop obsolete cpu_get/put in make_all_cpus_request Date: Tue, 21 Jul 2009 14:10:25 -0300 Message-ID: <20090721171025.GA6959@amt.cnet> References: <4A643924.6060908@siemens.com> <20090721000054.GB15189@amt.cnet> <4A657B28.5030006@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm-devel To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50557 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755753AbZGURLK (ORCPT ); Tue, 21 Jul 2009 13:11:10 -0400 Content-Disposition: inline In-Reply-To: <4A657B28.5030006@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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).