This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [TAPSETS] Linux Kernel Event Trace Tool
Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> [...]
> > I am probably missing something. Could you sketch out a scenario that
> > causes a safety problem?
> Let's think someone is probing a device which uses an NMI watchdog,
> and is interested to see if each event is really delivered to the
> CPU. In that scenario, if the tracer discards one event, then the
> user would have to restart the tracing. [...]
OK I understand, but that's not a safety problem.
> [...] The cleanest way I found to log NMIs without losing event is
> to make the logging code reentrant by itself by using atomic
> operations.
This approach may not work so easily for systemtap, since scripts have
a lot more local state (context) than a single tracing function call.
Plus they sometimes hold locks, during which reentrancy is bad.
"Guanglei Li" <guanglei@cn.ibm.com> wrote:
> So how about using semaphore in probe handler or spin lock in
> _stp_sprintf. So that no event will be lost.
Whom would such a spinlock protect against? There is intended to be
no locking that synchronizes separate CPUs running probes, except when
these scripts access shared ("global"-declared) systemtap variables.
> The current implementation will just abandon the processing of a
> probe handler if there's already another probe handler running, even
> on a different CPU.
Why do you think so? Reentrancy is assessed on a per-cpu basis.
Concurrency across CPUs is not explicitly blocked, except as above.
> > This will happend on systems where preemption is enabled if you do
> > not disable preemption. [...]
(We do need to disable preemption during probe handler execution.)
- FChE