Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758802Ab2BJBjW (ORCPT ); Thu, 9 Feb 2012 20:39:22 -0500 Received: from mail-qw0-f53.google.com ([209.85.216.53]:46031 "EHLO mail-qw0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754601Ab2BJBjV (ORCPT ); Thu, 9 Feb 2012 20:39:21 -0500 Date: Fri, 10 Feb 2012 02:39:14 +0100 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Avi Kivity , Christoph Lameter , Peter Zijlstra , Gilad Ben-Yossef , linux-kernel@vger.kernel.org, Chris Metcalf , linux-mm@kvack.org, Pekka Enberg , Matt Mackall , Sasha Levin , Rik van Riel , Andi Kleen , Mel Gorman , Andrew Morton , Alexander Viro , Michal Nazarewicz , Kosaki Motohiro , Milton Miller Subject: Re: [v7 0/8] Reduce cross CPU IPI interference Message-ID: <20120210013911.GM22552@somewhere.redhat.com> References: <4F2AB66C.2030309@redhat.com> <20120202170134.GM2518@linux.vnet.ibm.com> <4F2AC69B.7000704@redhat.com> <20120202175155.GV2518@linux.vnet.ibm.com> <4F2E7311.8060808@redhat.com> <20120205165927.GH2467@linux.vnet.ibm.com> <20120209152155.GA22552@somewhere.redhat.com> <4F33EEB3.4080807@redhat.com> <20120209182216.GG22552@somewhere.redhat.com> <20120209234144.GC2458@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120209234144.GC2458@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2579 Lines: 54 On Thu, Feb 09, 2012 at 03:41:45PM -0800, Paul E. McKenney wrote: > On Thu, Feb 09, 2012 at 07:22:19PM +0100, Frederic Weisbecker wrote: > > On Thu, Feb 09, 2012 at 06:05:07PM +0200, Avi Kivity wrote: > > > On 02/09/2012 05:22 PM, Frederic Weisbecker wrote: > > > > > > > > > > > > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which > > > > > > we can use. Hopefully they subsume rcu_virt_note_context_switch() so we > > > > > > only need one set of APIs. > > > > > > > > > > Now that you mention it, that is a good goal. However, it requires > > > > > coordination with Frederic's code as well, so some investigation > > > > > is required. Bad things happen if you tell RCU you are idle when you > > > > > really are not and vice versa! > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > Right. Avi I need to know more about what you need. rcu_virt_note_context_switch() > > > > notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same > > > > thing than rcu_idle_enter() minus the is_idle_cpu() checks). > > > > > > I don't know enough about RCU to say if it's okay or not (I typically > > > peek at the quick quiz answers). However, switching to guest mode is > > > very similar to exiting to user mode: we're guaranteed not to be in an > > > rcu critical section, and to remain so until the guest exits back to > > > us. > > > > Awesome! > > > > > What guarantees does rcu_user_enter() provide? With luck guest > > > entry satisifies them all. > > > > So rcu_user_enter() puts the CPU into RCU idle mode, which means the CPU > > won't need to be part of the global RCU grace period completion. This > > prevents it to depend on the timer tick (although for now you keep it) > > and to complete some RCU specific work during the tick. > > > > Paul, do you think that would be a win? > > As long as the code doesn't enter RCU read-side critical sections in > the time between rcu_idle_enter() and rcu_idle_exit(), this should > work fine. This should work fine yeah but further the correctness, I wonder if this is going to be a win. We use rcu_idle_enter() in idle to avoid to keep the tick for RCU. But what about falling into guest mode? I guess the tick is kept there so is it going to be a win in throughput or something to use rcu_idle_enter()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/