Hi guys,
Sorry about the slow response, bit distracted with the release and
other stuff yesterday.
----- Original Message -----
> On 08/13/2014 12:29 PM, William Cohen wrote:
> > On 08/13/2014 10:45 AM, David Smith wrote:
> >> [...] Once we get
> >> past the setup stuff in the begin probe, the update logic in do_update()
> >> is just sad. (Once again this isn't really a critique of your script,
> >> just the interface itself.) The way your script is forced to do updates
> >> doesn't really work - the only way this stuff will work as designed is
> >> that you actually keep the values in metric values, not copy stuff from
> >> systemtap variables into mmv values.
Yep, this kinda defeats the point of using MMV, and for this class of data
it'd make more sense to be doing sampling the same way as the rest of the
kernel (procfs, sysfs, open/read/close in userspace).
> >> Otherwise we're increasing the
> >> problem of inconsistent values between metric values.
*nod*
> > Another issue I had when creating the script was the relative static
> > creation of the mmv. Systemtap scripts often don't have an idea of what
There is the option of reshaping the mapping on-the-fly by changing
the generation numbers (timestamps) at the head of the mapped memory
and redefining, well, anything - the PMDA "rethinks its life" when it
sees a generation change, and rebuilds all data structures for that
mapping.
> > devices are used when the script runs and the script just makes a note in
> > an associative array of each device observed during the run. That
> > enumeration of possible values at startup is something that systemtap
> > scripts usually don't do.
Its not required by the MMV format (the userspace C API is simple though,
and it *does* expect entirely-up-front metric/instance definitions - its
simplicity possibly influenced your thinking with kernel APIs).
> >> With enough work, we could add some systemtap translator support and
> >> make this less clunky. However, I'm not sure that still solves the real
> >> problem here. This real script (as opposed to the fake script I've been
> >> using to develop) has really pointed out the problems here.
> >>
> >> Perhaps I'm being too pessimistic here.
*shrug*, maybe, maybe not. One thing we can be sure of - we know of no more
efficient way to expose this data, so its a good target to chase. It would
also be worthwhile reaching a point where we have end-to-end exporting of
metric values to obtain a performance baseline for any later investigations.
And, even with those later alternative mechanism, there will always be cases
where the least intrusive export mechanism will be needed - so, I for one do
continue to encourage your current line of work. Its also trivial from the
PCP side, since all the code already exists there.
cheers.
--
Nathan
|