Re: Controlling probe overhead

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

dsmith wrote:
> [...]
> >Note that the current code doesn't (intend to) truncate cycle counts,
> >just individual samples of the get_cycles() values.
> 
> Right, but the STP_OVERLOAD stuff needed full 64-bit values.  

There is some misunderstanding here.  The reason the STP_TIMING code
truncates cycles_t to 32 bits is because cycles_t can be wider than
the real cycle counter hardware on some machines.  There is no such
thing as "full 64-bit" everywhere.

> [...]
> Sorry, I wrote that from memory.  I went back and ran the test again, 
> and I get the overload message in roughly 2 seconds.  

OK.

> It takes another 60 seconds or so to deregister all the probes.

This part should get fixed soon, once the batch-unregister kprobes
code makes it upstream.  (Thanks for that, btw!)

>       cycles_t interval = (cycles_atend > c->cycles_base)
>         ? (cycles_atend - c->cycles_base)
>         : (STP_OVERLOAD_INTERVAL + 1);

BTW right here is where it will break if the actual hardware counter
is narrower than cycles_t.  If cycles_base was set near its overflow
point (which may be much less than 2**63), then even a brief probe
will end up with a cycles_atend < cycles_base.  That in turn would
lead to an erroneous overload indication.


> >>+  o->newline() << "#define STP_OVERLOAD_INTERVAL 1000000000LL";
> >>+  o->newline() << "#define STP_OVERLOAD_THRESHOLD 500000000LL";
> >
> >These quantities should probably depend on the processor, so that
> >overload intervals are measured in units of time rather than cycles.
>
> Hmm, those quantities do depend a bit on the processor, since cycles
> depend on the processor.  

What I meant was that the numbers need to change with the processor,
since a user will want to think in terms of time.


> However, trying to map time into cycles is typically a losing game,
> especially on systems with variable clock speeds.

It does not have to be perfect.  It just needs to produce reasonable
results for machines that could be along a 10-40x speed spectrum.


- FChE