From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper
Date: Fri, 27 May 2011 15:31:28 +0200
Message-ID: <20110527133128.GA23626@elte.hu>
References: <1306419950-19064-4-git-send-email-levinsasha928@gmail.com>
 <alpine.DEB.2.00.1105261901470.5480@tiger>
 <1306426743.3065.34.camel@lappy>
 <20110526180518.GA3572@elte.hu>
 <4DDE97CE.4000302@redhat.com>
 <BANLkTi=bMMr1zHWhwNsD=ah52n3ueoLbUg@mail.gmail.com>
 <20110526202531.GA2765@elte.hu>
 <20110526230508.GA15983@Krystal>
 <20110527102533.GA24608@elte.hu>
 <20110527132251.GD29744@Krystal>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Pekka Enberg <penberg@kernel.org>, Avi Kivity <avi@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, john@jfloren.net,
	kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com,
	prasadjoshi124@gmail.com,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx3.mail.elte.hu ([157.181.1.138]:35927 "EHLO mx3.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750839Ab1E0Nbi (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 27 May 2011 09:31:38 -0400
Content-Disposition: inline
In-Reply-To: <20110527132251.GD29744@Krystal>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> I'm worried about "self-recursion" behaviors that could be 
> triggered though: if the userland callback code called from a page 
> fault triggers a page fault all by itself, then it looks like a 
> good way to bring the system to its knees. [...]

Not really, SIGIO isnt being reprocessed until the signal handler 
returns.

> [...] The same apply to context switches. Do you have a way to 
> handle this in mind ?

Shouldnt be a problem in theory: yes, in case of repeat migrations 
repeat signals will be sent, but they should not nest in any nasty 
fashion.

That's the theory, it needs checking! :-)

One furthr optimization would be possible: in case you think we can 
write the signal handler in assembly or build it with gcc flags that 
does not use SSE we might also add a 'lightweight signal handler' 
kind of flag to the kernel, which does not save FPU/vector-CPU(SSE) 
state. In this case signals become *really* fast on x86, almost as 
fast as interrupts.

One detail: you'd not want to use a queueing signal, because the 
siginfo queue might overflow. It's also unnecessary: RCU only needs 
the last migration event, previous history is uninteresting.

Thanks,

	Ingo