Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754166AbbBFNlp (ORCPT ); Fri, 6 Feb 2015 08:41:45 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:35248 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751345AbbBFNlo (ORCPT ); Fri, 6 Feb 2015 08:41:44 -0500 Date: Fri, 6 Feb 2015 05:41:37 -0800 From: "Paul E. McKenney" To: Paolo Bonzini Cc: riel@redhat.com, kvm@vger.kernel.org, borntraeger@de.ibm.com, linux-kernel@vger.kernel.org, mtosatti@redhat.com, mingo@kernel.orgm, ak@linux.intel.com, oleg@redhat.com, masami.hiramatsu.pt@hitachi.com, fweisbec@gmail.com, lcapitulino@redhat.com Subject: Re: [PATCH 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit Message-ID: <20150206134137.GA5370@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1423167832-17609-1-git-send-email-riel@redhat.com> <1423167832-17609-2-git-send-email-riel@redhat.com> <20150205235526.GQ5370@linux.vnet.ibm.com> <54D4945D.8010703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D4945D.8010703@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15020613-0009-0000-0000-0000088EE11D Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5053 Lines: 138 On Fri, Feb 06, 2015 at 11:15:57AM +0100, Paolo Bonzini wrote: > > > On 06/02/2015 00:55, Paul E. McKenney wrote: > > On Thu, Feb 05, 2015 at 03:23:48PM -0500, riel@redhat.com wrote: > >> From: Rik van Riel > >> > >> Add the expected ctx_state as a parameter to context_tracking_user_enter > >> and context_tracking_user_exit, allowing the same functions to not just > >> track kernel <> user space switching, but also kernel <> guest transitions. > >> > >> Signed-off-by: Rik van Riel > > > > Acked-by: Paul E. McKenney > > /me wonders: whose tree is supposed to carry these patches? If no one else does, I would be happy to. I would be thinking in terms of 3.21, in other words, not the merge window starting in three days, but the one after that. Thanx, Paul > Paolo > > >> --- > >> include/linux/context_tracking.h | 12 ++++++------ > >> kernel/context_tracking.c | 10 +++++----- > >> 2 files changed, 11 insertions(+), 11 deletions(-) > >> > >> diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h > >> index 37b81bd51ec0..bd9f000fc98d 100644 > >> --- a/include/linux/context_tracking.h > >> +++ b/include/linux/context_tracking.h > >> @@ -10,21 +10,21 @@ > >> #ifdef CONFIG_CONTEXT_TRACKING > >> extern void context_tracking_cpu_set(int cpu); > >> > >> -extern void context_tracking_user_enter(void); > >> -extern void context_tracking_user_exit(void); > >> +extern void context_tracking_user_enter(enum ctx_state state); > >> +extern void context_tracking_user_exit(enum ctx_state state); > >> extern void __context_tracking_task_switch(struct task_struct *prev, > >> struct task_struct *next); > >> > >> static inline void user_enter(void) > >> { > >> if (context_tracking_is_enabled()) > >> - context_tracking_user_enter(); > >> + context_tracking_user_enter(IN_USER); > >> > >> } > >> static inline void user_exit(void) > >> { > >> if (context_tracking_is_enabled()) > >> - context_tracking_user_exit(); > >> + context_tracking_user_exit(IN_USER); > >> } > >> > >> static inline enum ctx_state exception_enter(void) > >> @@ -35,7 +35,7 @@ static inline enum ctx_state exception_enter(void) > >> return 0; > >> > >> prev_ctx = this_cpu_read(context_tracking.state); > >> - context_tracking_user_exit(); > >> + context_tracking_user_exit(prev_ctx); > >> > >> return prev_ctx; > >> } > >> @@ -44,7 +44,7 @@ static inline void exception_exit(enum ctx_state prev_ctx) > >> { > >> if (context_tracking_is_enabled()) { > >> if (prev_ctx == IN_USER) > >> - context_tracking_user_enter(); > >> + context_tracking_user_enter(prev_ctx); > >> } > >> } > >> > >> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c > >> index 937ecdfdf258..4c010787c9ec 100644 > >> --- a/kernel/context_tracking.c > >> +++ b/kernel/context_tracking.c > >> @@ -47,7 +47,7 @@ void context_tracking_cpu_set(int cpu) > >> * to execute won't use any RCU read side critical section because this > >> * function sets RCU in extended quiescent state. > >> */ > >> -void context_tracking_user_enter(void) > >> +void context_tracking_user_enter(enum ctx_state state) > >> { > >> unsigned long flags; > >> > >> @@ -75,7 +75,7 @@ void context_tracking_user_enter(void) > >> WARN_ON_ONCE(!current->mm); > >> > >> local_irq_save(flags); > >> - if ( __this_cpu_read(context_tracking.state) != IN_USER) { > >> + if ( __this_cpu_read(context_tracking.state) != state) { > >> if (__this_cpu_read(context_tracking.active)) { > >> trace_user_enter(0); > >> /* > >> @@ -101,7 +101,7 @@ void context_tracking_user_enter(void) > >> * OTOH we can spare the calls to vtime and RCU when context_tracking.active > >> * is false because we know that CPU is not tickless. > >> */ > >> - __this_cpu_write(context_tracking.state, IN_USER); > >> + __this_cpu_write(context_tracking.state, state); > >> } > >> local_irq_restore(flags); > >> } > >> @@ -118,7 +118,7 @@ NOKPROBE_SYMBOL(context_tracking_user_enter); > >> * This call supports re-entrancy. This way it can be called from any exception > >> * handler without needing to know if we came from userspace or not. > >> */ > >> -void context_tracking_user_exit(void) > >> +void context_tracking_user_exit(enum ctx_state state) > >> { > >> unsigned long flags; > >> > >> @@ -129,7 +129,7 @@ void context_tracking_user_exit(void) > >> return; > >> > >> local_irq_save(flags); > >> - if (__this_cpu_read(context_tracking.state) == IN_USER) { > >> + if (__this_cpu_read(context_tracking.state) == state) { > >> if (__this_cpu_read(context_tracking.active)) { > >> /* > >> * We are going to run code that may use RCU. Inform > >> -- > >> 1.9.3 > >> > > > -- 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/