| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] xm top values
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Jan Albrecht
> Sent: 18 December 2006 12:45
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] xm top values
>
> Hi all,
>
> does anybody know how the Dom0 values in xm top are calculated?
> Is this a accumulated value of all guest domains or how is ie. the CPU
> usage an own value?
Each domain gets a slice of the overall CPU performance - if 100% is
shown in the CPU usage category, then 100% of a single CPU-core is being
used by that domain [but that may be split, possibly unevenly, over 3
different CPU's according to the setup of the guest.
>
> Is there a way to see how much usage of the Dom0 is used by
> the guests?
Not as such - the usage in Dom0 is counted for and on behalf of Dom0,
not as part of the DomU guest that the service is provided for. It's not
IMPOSSIBLE to add such accounting, but I don't think it's entirely
trivial, as the split between what's for which guest can be hard to
determine. For example, we get a request to read a file for Dom1. It's
easy to tell who it's for when we get to the backend driver in Dom0, but
the backend request will result in a regular Dom0 file-read, which will
turn into a block read on the hard-disk - but the block-read will "wait"
for the data to return from the disk and wake up some time later. By
this time, knowing which guest was responsible for this request is
non-trivial to track unless we extend the entire Linux file (and
network) system call interface to have a further parameter to say "on
behalf of DomX" and add that to the accounting code. A fair amount of
work, and not necessarily very useful in the end (as there will still be
parts of execution that may not be very easy to account for - interrupt
or background tasks for example). The execution time in Linux is
accounted by the timer tick and when the process goes to sleep. If two
guests queue a network packet each in close succession, the network
sending thread may not go to sleep between the first and the second -
are we then going to account for both as the first sender?
--
Mats
>
> Thanks
> Jan
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home