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: Sun, 29 May 2011 16:27:47 +0200
Message-ID: <20110529142747.GA15441@elte.hu>
References: <20110526230508.GA15983@Krystal>
 <20110527102533.GA24608@elte.hu>
 <20110527110729.GA26920@elte.hu>
 <4DE13AF0.2080001@redhat.com>
 <20110528183259.GA15019@elte.hu>
 <4DE1EA93.6040401@redhat.com>
 <20110529073550.GA21254@elte.hu>
 <4DE1FBA5.6080905@redhat.com>
 <20110529123755.GC26627@elte.hu>
 <4DE2409D.1050701@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Pekka Enberg <penberg@kernel.org>,
	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: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.mail.elte.hu ([157.181.151.9]:45480 "EHLO mx2.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754170Ab1E2O2D (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 29 May 2011 10:28:03 -0400
Content-Disposition: inline
In-Reply-To: <4DE2409D.1050701@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Avi Kivity <avi@redhat.com> wrote:

> I don't understand how you expect per_cpu to work in userspace.  As 
> soon as you calculate the per-cpu address, it can be invalidated. 
> It doesn't help that you get a signal; you've already calculated 
> the address.

I was thinking of some sort of transactional mechanism, a tightly 
controlled set of assembly instructions updating the percpu fields, 
where the migration event would be able to 'unroll' incomplete 
modifications done to the 'wrong' percpu data structure. (It would be 
rather complex and every percpu op would have to be an atomic because 
there's always the chance that it's executed on the wrong CPU.)

But note that we do not even need any notification if there's a 
(local) lock on the percpu fields:

It will work because it's statistically percpu the lock will not 
SMP-bounce between CPUs generally so it will be very fast to 
acquire/release it, and we get the full cache benefits of percpu 
variables.

The migration notification would still be useful to detect grace 
periods at natural points - but as Paul pointed out polling it via 
SIGALRM works as well. The two (migration and SIGALRM) could be 
combined as well.

Thanks,

	Ingo