From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Sun, 29 May 2011 14:37:55 +0200 Message-ID: <20110529123755.GC26627@elte.hu> References: <20110526202531.GA2765@elte.hu> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Avi Kivity Return-path: Received: from mx3.mail.elte.hu ([157.181.1.138]:56817 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111Ab1E2MiO (ORCPT ); Sun, 29 May 2011 08:38:14 -0400 Content-Disposition: inline In-Reply-To: <4DE1FBA5.6080905@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Avi Kivity wrote: > On 05/29/2011 10:35 AM, Ingo Molnar wrote: > >* Avi Kivity wrote: > > > >> On 05/28/2011 09:32 PM, Ingo Molnar wrote: > >> >* Avi Kivity wrote: > >> > > >> >> > So if you set a notification signal via fcntl(F_SETOWN) on the > >> >> > scheduler context switch event fd, the user-space RCU code will > >> >> > get a signal on every context switch. > >> >> > >> >> Context switches are completely uninteresting for userspace rcu: > >> >> > >> >> rcu_read_lock(); > >> >> ---> context switch > >> >> > >> >> have we learned anything from that? no. User code is always > >> >> preemptible and migratable. If rcu_read_lock() prevented migration > >> >> somehow, then we'd know that a context switch means we've started a > >> >> grace period for this thread. But it doesn't, so we don't. > >> > > >> >Well, in the next mail i mentioned that we can do migration events as > >> >well, which would be useful: instead of having to keep track of > >> >nr_tasks RCU grace periods we could simplify it down to nr_cpus. > >> > >> I don't see how a migration event helps. It is completely > >> transparent from the task's point of view. > > > > It's not transparent at all if you index RCU data structures by > > the current CPU index, which the kernel implementation does. > > But that's completely broken for userspace. The "current cpu > index" doesn't even exist, since you can't disable preemption. It does exist, if the signal handler notification of a migration is instantaneous (which it is). > > Doing that has the advantage of being much more cache-compressed > > than the TID index, > > If you have more tasks than cpus; which isn't a given. Sure there are special cases but in general there can be many more tasks (threads) than CPUs ;-) Thanks, Ingo