From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Sun, 29 May 2011 18:00:00 +0300 Message-ID: <4DE25F70.5080700@redhat.com> 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> <20110529142747.GA15441@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mathieu Desnoyers , Pekka Enberg , Sasha Levin , john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6337 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753476Ab1E2PAl (ORCPT ); Sun, 29 May 2011 11:00:41 -0400 In-Reply-To: <20110529142747.GA15441@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 05/29/2011 05:27 PM, Ingo Molnar wrote: > * Avi Kivity 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. > I think it's way simpler to map cpu == thread. And in fact, when you run a Linux kernel in a kvm guest, that's what happens, since each vcpu _is_ a host thread. -- error compiling committee.c: too many arguments to function