lkml.org 
[lkml]   [2009]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] tracing/filters: allow event filters to be set only when not tracing
On Mon, Apr 06, 2009 at 08:34:20PM -0400, Steven Rostedt wrote:
>
>
> On Mon, 6 Apr 2009, Paul E. McKenney wrote:
> >
> > Hmmm... Do the start_critical_timings() and stop_critical_timings()
> > functions have anything to do with ftrace()?
>
> Yep.
>
> > It does not look like I can just bury RCU-idle controls in these
> > functions, given that they are also invoked around call_console_drivers(),
> > but if all the idle loops are surrounded by stop_critical_timings() and
> > start_critical_timings(), that would ease location of all the idle
> > loops. ;-)
>
> They are for the irqsoff tracer. Several archs will disable interrupts and
> call an assembly "halt" type instruction that can be woken up by
> interrupts. But this skips the irqs off check, and we end up with irqsoff
> showing the idle loop with huge interrupts off latencies.
>
> I'm not sure they are included in all archs. They may be.

Not a chance! :-(

Looks like one can poke into cpu_idle() on all arches, but looks like
I cannot even assume that I can leverage CONFIG_NO_HZ due to the
rcu_needs_cpu() case. See below for my rough (and almost certainly
erroneous) notes thus far.

Thoughts?

Thanx, Paul

------------------------------------------------------------------------

o Have rcu_idle() call from spinning idle loops. This would
invoke rcu_qsctr_inc() and rcu_bh_qsctr_inc().

In this case, rcu_check_callbacks() need only check for
interrupt from user-level code.

o But this won't work for idle loops that yield to a hypervisor
without being in nohz node. For these, do rcu_idle_start()
before the yield and rcu_idle_end() after the yield. These
would manipulate a per-CPU variable.

In this case, rcu_check_callbacks() needs to check for:

a. interrupt from user-level code

b. unnested interrupt while under the influence of
rcu_idle_start().

o Put rcu_idle_start() after stop_critical_timings() and put
rcu_idle_end() before start_critical_timings() in each arch's
idle loop. But maybe pick less confusing names...

o powerpc: looks OK.

o s390: looks OK -- always dyntick.

o Super-H: Looks OK -- always dyntick.

o x86 32-bit: Looks OK. This is cpu_idle() in
arch/x86/kernel/process_32.c.

o x86 64-bit: Looks OK.

o ACPI: Looks OK.

o x86 APM: invokes system default idle, so OK if that is OK.

o x86: default_idle() in arch/x86/kernel/process.c
need rcu_idle_start() and rcu_idle_end(), or ensure
that caller always does the right thing???

o cpuidle_idle_call() in drivers/cpuidle/cpuidle.c
needs rcu_idle_start() and rcu_idle_end()???

o ARM: Looks OK -- always dyntick. See cpu_idle() in
arch/arm/kernel/process.c.

o Blackfin: Looks OK -- always dyntick. see cpu_idle() in
arch/blackfin/kernel/process.c.

o Cris: ??? cpu_idle() in arch/cris/kernel/process.c
has strange comment:

* Mark this as an RCU critical section so that
* synchronize_kernel() in the unload path waits
* for our completion.

Ain't gonna happen...

But looks like we need an rcu_start_idle() and an
rcu_stop_idle() around the call to idle().

o H8300: cpu_idle() in arch/h8300/kernel/process.c.

Need an rcu_start_idle() and an rcu_stop_idle() around
the call to idle(). Hopefully not messing too much with
the exit latency.

o IA64: cpu_idle() in arch/ia64/kernel/process.c.

Need an rcu_start_idle() and an rcu_stop_idle() around
the call to idle(). Not sure how far around...

o M68k: cpu_idle() in arch/m68k/kernel/process.c.

Need an rcu_start_idle() and an rcu_stop_idle() around
the call to idle(). Hopefully not messing too much with
the exit latency.

o M68Knommu: Ditto, but arch/m68knommu/kernel/process.c.

o UM: Looks OK -- always nohz.

o M32r: cpu_idle() in arch/m32r/kernel/process.c.

Need an rcu_start_idle() and an rcu_stop_idle() around
the call to idle(). Hopefully not messing too much with
the exit latency.

o MN10300: cpu_idle() in arch/mn10300/kernel/process.c.

Need an rcu_start_idle() and an rcu_stop_idle() around
the call to idle(). Hopefully not messing too much with
the exit latency.

@@@ Need to recheck the "nohz OK" assumption -- might have disabled it.
Maybe make rcu_idle_start() and rcu_idle_stop() no-ops in case
of CONFIG_NO_HZ -- but still need rcu_needs_cpu() case to work.
So follow up on cpu_idle() cases.

o Idle loops (for posterity's sake):

o Generic: default_idle() gets rcu_idle().

o Power: All invoked from cpu_idle(), which already contains
stop_critical_timings() and start_critical_timings().

o 44x: ppc44x_idle() absolutely unclear.

o powermac: power4_idle() is assembly code???

Appears to need a call to rcu_idle() in
the loop headed by label 1b:.

o maple: same as powermac.

o pseries: pSeries_setup_arch()

o pseries_shared_idle_sleep()
needs rcu_idle_start() and
rcu_idle_end() surrounding
the cede_processor() call.

o pseries_dedicated_idle_sleep()
needs rcu_idle_start() and
rcu_idle_end() surrounding
the cede_processor() call.
Might also need rcu_idle() in
the "while" loop...

o iseries: iSeries_setup_arch()

o iseries_shared_idle() seems to need
rcu_idle_start() and rcu_idle_end()
surrounding yield_shared_processor()
call.

o iseries_dedicated_idle() needs no
action, as it forces nohz. ;-)

o pasemi: modes[] array in platforms/pasemi/idle.c

o idle_spin() assembly function, need
call to rcu_idle() in loop headed by
label 1:.


\
 
 \ /
  Last update: 2009-04-07 03:31    [W:0.060 / U:0.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site