Re: [Libvir] [PATCH] Block device and network stats (version 2)
On Tue, Aug 21, 2007 at 09:02:45AM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
>>This patch adds block device and network stats. The main changes over
>>the previous version are:
>>
>>* Remote support.
>>* Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
>>
>>Discussions about the previous version may be found starting here:
>>https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
>>
>>I have left use of stdint.h / int64_t, since it wasn't clear to me what
>>conclusion people had arrived at.
>
>Personally I'm for using long long, since its consistent with the other
>existing APIs using 64 bit quantities. They're both standards so there's
>no much of a reason to favour one over the other.
I favour int64_t, because I want 64 bit integers (signed in this case
because I want the special -1 value). C doesn't specify a maximum width
for "long long".
>I notice the Xen impl of the block stats only fills in the rd_req and
>wr_req
>fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
>512 bytes in size ? If so, should be just junk those fields and only return
>data in terms of the bytes (other units can be calculated as needed). As a
>point of reference libstatgrab only returns bytes read/written for disks.
I assumed that Xen requests were variable in size ... That is based on
my reading of this code from blkif.h:
Ok, yes I they are variable size. I was mixing up requests vs sectors, the
latter being fixed, the former being variable since they can be made up of
multiple sectors.
If it is true that requests have a fixed size, then returning bytes
_also_ would be good, but I suspect that we should also still return
requests as well since (a) it costs virtually nothing to do so, and (b)
it might be interesting to find the average size of each request, since
lots of small requests are likely to be less efficient than small
numbers of large requests.
Yes, we need both. If we can't find actual request sizes for Xen, we should
make a note and see if its possible add this to future Xen kernel backend
drivers.
>For hdNNN based disks it seems to be
>
> ide major number corresponding to disk letter * 256 + minor number
> as calculated from partition numbers.
OK ... I've never seen Xen guests with sdX/hdX devices. Are they common?
Any HVM guest.... A lot of people do use them in paravirt too, we refuse
to use it in Fedora because the ability to hijack hdN and sdN was disappearing
in paravirt_ops Xen merge. So hopefully not so common in future, but we'll
likely hit them periodically in the wild
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|