Hi David,
----- Original Message -----
> [...]
> At this point most of it is in my head. But, here's the original plan
> (although "plan" is probably too strong a word at this point). The plan
:) Please do send an RFC (nothing formal) out to the pcp list once some
ideas start to fall into place, and you have a good direction in mind to
head down - lots of heads older & more experienced than mine lurk here.
Keep in mind that we could partition the MMV code in such a way that the
generalised metric description side of things is separate from the value
reading side of things, if that helps. e.g. It may make sense to use the
former but with a different value-reading strategy perhaps (there's a bit
of complexity in managing the metrics/instance offsets, that might not
make sense to put into the kernel - even via systemtap; and perhaps using
the existing sysfs/proc file/dir mechanisms would be a better fit).
There are also subtle issues with MMV as we discussed, in terms of having
to synchronise the instrumented application (or kernel) view of metrics,
with whats exported - sometimes direct memory value is not sufficient, and
calculations may need to be made on a value before its exported. With a
memory mapping that is made tricky (since it can be sampled any time with
no coordination between the process doing the sampling, and the code doing
the exporting). Whereas, the usual way of sampling (proc/sysfs reader or
whatever) has a natural sample time point where such transformations, or
collections (e.g. perhaps summing all in-flight-I/O times - that kind of
thing), can be made.
See MMV_TYPE_ELAPSED for one approach that's been used there in the past,
that'll give an example of this class of problem anyway - it is a more
general problem than the specific one solved by that MMV type though.
cheers.
--
Nathan
|