https://bugzilla.redhat.com/show_bug.cgi?id=1296750
--- Comment #6 from Frank Ch. Eigler <fche@xxxxxxxxxx> ---
Thanks for your analysis!
One possibility for solution would be reinterpreting the responsibility
of interp.c, not simply to deliver a value between two samples in an
archive (ie., samples at time=t{1,2,3,4,5}), but to also consider the
times of the pmFetch time-cursor values t=t{A,B,C,D}.
interp.c could recognize that between the previous pmFetch and the
current one (tA and tB), there occurred a <mark>, and refuse to provide
a result:
t1 value
tA (fetch)
t2 value
t3 <mark>
t4 value
tB (fetch)
t5 value
... so even though tA and tB could be defined in isolation (as a function
of t{1,2} and t{4,5} respectively), interp.c could reject it because of
the <mark> between tA and tB. (Maybe it could do this for SEM_COUNTER
only.)
This would cost applications a lost interp-mode sample across mark
boundaries, but that's all. pmrep etc. would just work (tm).
This reading of PM_MODE_INTERP doesn't seem incompatible with pmSetMode's
documentation, or the programming guide. The first just says it computes
"values [...] in the "proximity of the time origin", not just the two
adjacent ones. This could be a good time to document <mark> in pmSetMode's
man page.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=gSL3nCPy0m&a=cc_unsubscribe
|