RE: Enabling irqs in begin/end probes

["Stone, Joshua I" <joshua dot i dot stone at intel dot com>]

On Wednesday, January 10, 2007 9:51 PM, Mike Mason wrote:
> Last week I was asked to explain why enabling irqs in begin/end
> probes might be desired.  I haven't run into a specific need to
> enable irqs in end probes, but my recent argtap post shows an example
> for begin probes.   

The core issue is that you'd like to be able to take an action that
might sleep.  Sleeping requires irqs enabled as well as preemption.
(Are there any other conditions required for a valid "sleepy" context?)

Here are the challenges that I see:

1. Context variables are per-cpu.  We use a special context throughout
generated code to minimize stack usage.  This context contains local
variables, intermediate values, and function parameters and return
values.  This presents a challenge if we migrate to another cpu while
sleeping or being preempted.

2. As a general rule, we allow the assumption that irqs are disabled in
the runtime and in tapset functions.  If we invalidate this assumption,
we'll need to make sure that none of the code depends on this condition.

3. There may be unforseen consequences to script writers as well.  For
instance, a user can currently depend on cpu() being consistent
throughout the execution of a probe.  I'm not sure why anyone would
reference the cpu number in a begin/end probe, but it's something to
think about.


When I think closer about #1, it might not be a problem after all.  The
main reason for the context to be per-cpu is to allow concurrent probe
execution -- but begin/end probes are run sequentially.  The probes
index their context by cpu id only once, and then use that pointer
throughout.  Thus I think it doesn't matter if the probe is migrated to
another cpu.  It's ok if a begin probe starts on cpu0, migrates to cpu1,
and continues using cpu0's context, because we know that no probe will
run on cpu0 at the same time, and the probe will keep a consistent
context.

We still need to consider #2 and #3 though.


Josh