RE: offline elfutils processing committed

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

On Tuesday, October 31, 2006 6:13 PM, Frank Ch. Eigler wrote:
> Hi -
> 
> A big commit went in just now [...]

cvsps | diffstat says:
 11 files changed, 1058 insertions(+), 1849 deletions(-)

Big indeed!  I hope the testsuite is up to the task... :)

I'll address the XXX notes you added to the hrtimer stuff:


In hrtimer_derived_probe_group::emit_interval:
// XXX: why not use stp_random_pm instead of this?
(re: code that generates randomization of timer interval)

The easy-out answer is that stp_random_pm deals with ints, and I needed
the randomization to be 64-bit.  I'll concede that it's probably better
to add an stp_random_pm_64.  I also thought that using the kernel's
get_random_bytes would yield better randomization than the pseudo-random
generator in stp_random_pm.  I guess the quality of randomization could
be addressed in the runtime function.

On a related note, you broke the randomization on jiffies timers when
used as ms.  The random value needs to be added *before* the conversion
to jiffies.  It's also an optimization to gate the random-call on
whether a randomization value is present.  I'll make these corrections
shortly.


In hrtimer_derived_probe_group::emit_module_decls:
// presume problem with updating ->expires or something else XXX
(re: the restart_or_not variable)

This was a fix for bz #3278.  The problem was that at the end of a
session, the probe prologue skipped skipped over the probe, and the
timer got restarted with the same expiration.  With this change it only
restarts if the expiration was updated.

But, this brings to mind a potential race in the startup, with both
hrtimers and jiffies-timers.  In both cases, the timer only gets
restarted if we run the probe, which only happens if the state is
STAP_SESSION_RUNNING.  If a newly registered timer fires off while we're
still initializing other code (STAP_SESSION_STARTING), the timer won't
be restarted, and it will be useless for the whole session.

I'm actually surprised we haven't had a problem with this yet, as it's a
pretty simple race condition.  I guess there's not many people using
very short timer intervals.  In any case, I'm not sure of an elegant way
to fix it -- suggestions?


Josh