On Mon, 14 Jul 2008, Mathieu Desnoyers wrote:

quoted text
>
> (CC'ed LKML)
>
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> >
> > On Mon, 14 Jul 2008, Mathieu Desnoyers wrote:
> > >
> > > Thanks a lot Steve! By the way, you might be interested in looking at
> > > the extra tracing enable/disabled tests you have in ftrace : it should
> > > be enough to register/unregister the probes to activate/deactivate
> > > tracing. I don't see why you would need if() checks in the probe itself.
> > >
> >
> > That was actually one of the causes of the bugs I had. We had two markers,
> > one tracing schedule switches, the other wake ups. As soon as one is
> > enabled, tracing starts, and you will miss the tracing of the other one.
> >
> > The result was a strange trace were things were waking up then the waker
> > was being scheduled in??
> >
> > I need to enable all markers at the same time, which can be done with the
> > if () check. Not to mention, I like to be able to shut of tracing on oops
> > without needing to do anyting drastic (like deactivating probes).
> >
> > -- Steve
> >
>
> I see the reason why you need this, but beware that the activation
> boolean you are using in your check won't be seen as active at the same
> time by all CPUs because of out-of-order read/writes. So while the
> update is per se atomic, the replication of the updated value to all
> processors isn't. However, when one CPU sees the new version, this
> version will stay valid.

Yep, I understand that. It was that the same CPU trace provided funny
output. It it were a trace over separate CPUS then that is something
people would accept.

quoted text
>
> This is one of the reasons why I don't aim to provide atomic activation
> of multiple markers : thinking that the state will be atomically changed
> on all CPUs without using the proper memory barriers is a bit bogus
> anyway. Does ftrace expect such atomic propagation of the change across
> all CPUs or does it deal with the information it receives on a per-cpu
> basis ?

All the buffers and traces are per-cpu. We sort out the rest on output,
and we use the clock as the interleaver. Doing that doesn't guarantee that
events actually do happen in the order that appear, but it gives one a
good idea of where to look.

quoted text
>
> In any case, you should also make sure that you call synchronize_sched()
> after the probe registration to make sure the quiescent state is reached
> and that all probes are connected (so that no marker still see the old
> data structures). This should be done before you activate your boolean
> in the probes.

Good to know, thanks. Hmm, I'm not sure that code can schedule :-/ Maybe
it can. I'll have to take a look.

quoted text
>
> I agree that the extra check is very well suited to the OOPS case.


Thanks,

-- Steve

--
unsubscribe notice
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/