From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle Date: Fri, 03 Feb 2012 11:12:49 -0800 Message-ID: <87ty37689a.fsf@ti.com> References: <20120202004253.GA10946@linux.vnet.ibm.com> <1328143404-11038-1-git-send-email-paulmck@linux.vnet.ibm.com> <1328143404-11038-2-git-send-email-paulmck@linux.vnet.ibm.com> <20120202044439.GD2435@linux.vnet.ibm.com> <20120202174337.GS2518@linux.vnet.ibm.com> <20120202190708.GE2518@linux.vnet.ibm.com> <87obtgc1xx.fsf@ti.com> <20120202230326.GJ2518@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120202230326.GJ2518@linux.vnet.ibm.com> (Paul E. McKenney's message of "Thu, 2 Feb 2012 15:03:26 -0800") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: paulmck@linux.vnet.ibm.com Cc: Nicolas Pitre , mathieu.desnoyers@polymtl.ca, peterz@infradead.org, fweisbec@gmail.com, Nicolas Ferre , dhowells@redhat.com, Lennert Buytenhek , Kukjin Kim , Russell King , eric.dumazet@gmail.com, H Hartley Sweeten , Magnus Damm , Tony Lindgren , dipankar@in.ibm.com, darren@dvhart.com, mingo@elte.hu, Jean-Christophe Plagniol-Villard , Len Brown , Amit Kucheria , patches@linaro.org, Will Deacon , josh@joshtriplett.org, Sekhar Nori , niv@us.ibm.com, linux-samsung-soc@vger.kernel.org, rostedt@goodmis.org, Barry Song , tglx@linutronix.de, linux-omap@vger.ke List-Id: linux-omap@vger.kernel.org "Paul E. McKenney" writes: > On Thu, Feb 02, 2012 at 02:20:26PM -0800, Kevin Hilman wrote: >> "Paul E. McKenney" writes: >> >> [...] >> >> >> > The two options I see are: >> >> > >> >> > 1. Rip tracing out of the inner idle loops and everything that >> >> > they invoke. >> >> >> >> What I suggested above. But as I said I know sh*t about that tracing >> >> implementation so that's an easy suggestion for me to make. >> > >> > Works for me as well. ;-) >> >> While I must admit not having a better suggestion, I for one would vote >> strongly against removing tracing from the idle path. >> >> Being a PM developer and maintainer, much of the code I work on and >> maintain happens to be run in the bowels of the idle path. Not having >> the ability to trace this code would be a major step backwards IMO. > > OK... > > What if the tracing code between the rcu_idle_enter() and the > rcu_idle_exit() had to be enclosed in a wrapper? For example, > the tracing in cpuidle_idle_call() might appear as follows: > > RCU_NONIDLE( > trace_power_start(POWER_CSTATE, next_state, dev->cpu); > trace_cpu_idle(next_state, dev->cpu); > ); > > entered_state = target_state->enter(dev, drv, next_state); > > RCU_NONIDLE( > trace_power_end(dev->cpu); > trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu); > ); > > The RCU_NONIDLE() macro would do rcu_idle_exit(), execute its > argument, then do rcu_idle_enter(). (Credit to Steven Rostedt > for suggesting this.) Given the possibility of code invoked both > from idle and not-idle, I have some changes to rcu to allow nesting > of rcu_idle_enter() and rcu_idle_exit(). > > Would that work for you? Yes, that should work. And I defintely have examples of code paths that use tracepoints in both idle and non-idle context (power domains, clocks, etc.) so the changes to allow nesting will be needed. Thanks, Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Fri, 03 Feb 2012 11:12:49 -0800 Subject: [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle In-Reply-To: <20120202230326.GJ2518@linux.vnet.ibm.com> (Paul E. McKenney's message of "Thu, 2 Feb 2012 15:03:26 -0800") References: <20120202004253.GA10946@linux.vnet.ibm.com> <1328143404-11038-1-git-send-email-paulmck@linux.vnet.ibm.com> <1328143404-11038-2-git-send-email-paulmck@linux.vnet.ibm.com> <20120202044439.GD2435@linux.vnet.ibm.com> <20120202174337.GS2518@linux.vnet.ibm.com> <20120202190708.GE2518@linux.vnet.ibm.com> <87obtgc1xx.fsf@ti.com> <20120202230326.GJ2518@linux.vnet.ibm.com> Message-ID: <87ty37689a.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org "Paul E. McKenney" writes: > On Thu, Feb 02, 2012 at 02:20:26PM -0800, Kevin Hilman wrote: >> "Paul E. McKenney" writes: >> >> [...] >> >> >> > The two options I see are: >> >> > >> >> > 1. Rip tracing out of the inner idle loops and everything that >> >> > they invoke. >> >> >> >> What I suggested above. But as I said I know sh*t about that tracing >> >> implementation so that's an easy suggestion for me to make. >> > >> > Works for me as well. ;-) >> >> While I must admit not having a better suggestion, I for one would vote >> strongly against removing tracing from the idle path. >> >> Being a PM developer and maintainer, much of the code I work on and >> maintain happens to be run in the bowels of the idle path. Not having >> the ability to trace this code would be a major step backwards IMO. > > OK... > > What if the tracing code between the rcu_idle_enter() and the > rcu_idle_exit() had to be enclosed in a wrapper? For example, > the tracing in cpuidle_idle_call() might appear as follows: > > RCU_NONIDLE( > trace_power_start(POWER_CSTATE, next_state, dev->cpu); > trace_cpu_idle(next_state, dev->cpu); > ); > > entered_state = target_state->enter(dev, drv, next_state); > > RCU_NONIDLE( > trace_power_end(dev->cpu); > trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu); > ); > > The RCU_NONIDLE() macro would do rcu_idle_exit(), execute its > argument, then do rcu_idle_enter(). (Credit to Steven Rostedt > for suggesting this.) Given the possibility of code invoked both > from idle and not-idle, I have some changes to rcu to allow nesting > of rcu_idle_enter() and rcu_idle_exit(). > > Would that work for you? Yes, that should work. And I defintely have examples of code paths that use tracepoints in both idle and non-idle context (power domains, clocks, etc.) so the changes to allow nesting will be needed. Thanks, Kevin