Patch: cpu utilization monitor.

[Mike Kravetz]

On Wed, Mar 17, 2004 at 11:13:59AM -0800, Dave Hansen wrote:
>
> 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?
>

Actually, this type of data sounds like something that (forgive me
for mentioning this!!!) the IBM eWLM product would want to know.
I don't think CKRM, or the OS can do much with this type of data
except report it for further analysis.  More interesting is what
something that let's say 'controls the entire machine' can do with
this data.  For example, one OS isn't getting enough CPU cycles
and another OS has excess cycles.  Let's turn the knobs to balance
things out at the machine/hypervisor level.

Perhaps this is what was meant by Linas's original reference to
'on demand'?

--
Mike

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