[collectd] [PATCH] lpar plugin: use pool_idle_time to account for cpu pool usage

[Florian Forster]

Hi Aurelien,

On Thu, Sep 23, 2010 at 11:29:49AM +0200, Aurelien Reynaud wrote:
> The current implementation uses pool_busy_time (expressed in ns) but
> experience shows this metric isn't accurate: It shows lower cpu usage
> for the entire pool than the sum of the participating lpars.
> Using pool_idle_time (expressed in clock ticks) in contrast is almost
> a perfect match.

thanks for the update! :) So what you're saying is that "busy + idle"
may not be equal to "max"? If so, What happens to the missing CPU
cycles? Would it make sense to keep track of this separately? Something
like "missing = max - (idle + busy)" could be used, for example.

I think I remember something about ticks varying in the time they
consume, due to power-saving facilities built into the CPUs. This would
explain why the (physical) CPU time available to the cluster is measured
in nanoseconds rather than ticks. Also, if there are more and shorter
ticks in the same wallclock time due to power-saving measures, this
would explain the perceived lower CPU usage when converting the ns back
to ticks using a larger "ns per tick" constant. So maybe the "missing"
metric above could be named "power_save". What do you think?

Regarding the patch, I'd like to propose one tweak:

> -#define NS_TO_TICKS(ns) ((ns) / XINTFRAC)
> [...]
> +		pool_idle_cpus = (double) (lparstats.pool_idle_time - lparstats_old.pool_idle_time) / XINTFRAC / (double) ticks;

I'd really like to keep this macro: "diff / XINTFRAC / ticks" doesn't do
a good job at describing to the reader what's going on. With the macro
this becomes "NS_TO_TICKS (diff) / ticks": you can see without looking
at the macro's implementation that "diff" is converted from nanoseconds
to ticks and then divided by ticks, which results in a ratio.

Best regards,
--octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x0C705A15
http://octo.it/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20100926/96945e73/attachment.pgp>