Patch: cpu utilization monitor.

[Dave Hansen]

On Wed, 2004-03-17 at 10:56, linas at austin.ibm.com wrote:
> This patch differs from other efforts in that it gets data directly from
> the hypervisor.  Think multiple virtual cpus running on one physical cpu.
> The traditional tools, whether CKRM or top or vmstat, are blind to the
> fact that any given 'virtual cpu' might be getting only 10% of the physical
> cycles in one hypervisor time-slice, and 90% in another.
>
> Very crudely, its sort-of like VM on the 390/zSeries.  Your kernel may
> think its 100% busy, but in fact it might be getting only 1% of the actual
> physical hardware cycles.  The goal here is to be able to report the
> fraction of the total physical cycles, and do so on a HZ or even sub-HZ
> level of granularity.

But, the number is still just another performance counter, right?  Is
the interface to fetch it the same as the other CPU performance
counters?

I think what Greg was getting at is that CKRM aims to be able to make
resource decisions based on data it gets from all kinds of sources,
including performance counters.  If you export this 'virtual cpu' slice
in the same way that other CKRM-handled data are, then you can probably
access it in whatever way you wanted, and you get the code reuse benefit
of using the rest of the CKRM work.  Shailabh, am I on the right track
here?  I'm kinda guessing at what the CKRM goals are here.

What is the planned use of this counter?  Will it simply be exported to
userspace, or will the kernel need it internally for something?

-- dave


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/