On Fri, May 25, 2012 at 10:56:31AM -0400, Chad Mynhier wrote:
> Responses inline:
>
> On Thu, May 24, 2012 at 6:56 PM, <chip.benn...@exeloncorp.com> wrote:
> > Chad,
> >
> > That was very helpful, thank-you.
> >
> > So it sounds like you're saying that if the check expression has no
> > cacheable components, it doesn't matter if I put the check in the
> > predicate, or if I break the logic into two clauses and put the check
> > in the first clause, with a thread-local variable to trigger the second
> > clause.
>
> Well, actually, you would see some benefit from breaking it into two
> clauses, if the predicate from the first clause is cacheable (like
> /execname == "oracle" /.) And you would see some benefit from the
> second clause if its predicate is also cacheable.
Also, remember that predicate caching only remembers the *last* cachable
predicate the current thread evaluated, so it is mostly useful for predicates
which will be hit more than once by a particular thread.
For example, something like:
fbt::: /self->foo/ {
/* XXX do something */
}
fbt::: /self->foo/ {
/* XXX do something */
}
is actually pessimal, since the predicate cache will always be out of date.
(the fact that the two predicates are identical is not recognized; so each
gets assigned a separate "predcache" ID). The logic in dtrace is:
if (probe->predcache != DTRACE_CACHEIDNONE &&
probe->predcache == curthread->t_predcache) {
/* fail immediately */
}
...
evaluate predicate
if (predicate is false) {
if (probe->predcache != DTRACE_CACHEIDNONE) {
curthread->t_predcache = probe->predcache;
}
continue;
}
In fact, any time you have more than one enabling for a probe with a predicate,
the probe's 'predcache' will be DTRACE_CACHEIDNONE, since the two enablings
cannot (as it stands) have the same predcacheid.
There are three directions which could be explored to improve this:
1. Extend the predicate cache to actually compare the DIFO of active
predicates, so that identical predicates get the same
predcacheid. That would significantly improve the flexibility
for consumers, since you can have different action statements for
different probes.
2. Increase the predcache depth (allow multiple t_predcache IDs).
This might not be worth it, since we check the cache on every
probe firing.
3. We could investigate checking the predcache before evaluating the
predicate, which could help for complicated predicates. But
the benefit of the predcache is really that it drops out of dtrace
processing as early as possible; this would have less of an effect.
#1 seems like the biggest win to me.
Cheers,
- jonathan
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
