Xen devel - Jun 2006 - [PATCH 1/3] Output Virtual Block Device requests information to /proc/xen/vbd

This patch add /xen/proc/vbd.
This proc file stores counts of I/O requests for VBD.
I/O requests is counted for each Domains.

For example, in case of four VMs, outputs of reading /xen/proc/vbd are as
follows.

root@dom0 ~]# more /proc/xen/vbd
Domain 4 - oo        0  rd    18699  wr        2
 xvd 4  8:21 - oo        0  rd    18699  wr        2
Domain 7 - oo        0  rd      869  wr      376
 xvd 7  8:22 - oo        0  rd      869  wr      376
Domain 8 - oo        0  rd      721  wr      197
 xvd 8  8:23 - oo        0  rd      721  wr      197
Domain 9 - oo        0  rd      640  wr       77
 xvd 9  8:24 - oo        0  rd      640  wr       77

The outputs show the following information.

The first line shows domain information.
     Detail: Domain [Domain ID] - oo [oo-reqs] rd  [rd-reqs] wr [wr-reqs].
The second or less than third line shows each VBD information.
        xvd [Domain ID] [device majar]:[device minor]  - oo [oo-reqs] rd 
[rd-reqs] wr [wr-reqs].

VBD information handles "xvd [Domain ID] [device majar]:[device
minor]" for reason
 that the thread is running same name.

Currently, Domain show domain ID.
Someday, it want to correspond with domain name.


Thanks,
Satoshi UCHIDA


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/21/06, Satoshi Uchida <s-uchida@ap.jp.nec.com>
wrote:
>
> This patch add /xen/proc/vbd.
> This proc file stores counts of I/O requests for VBD.
> I/O requests is counted for each Domains.
>
> For example, in case of four VMs, outputs of reading /xen/proc/vbd are as
follows.
>
> root@dom0 ~]# more /proc/xen/vbd
> Domain 4 - oo        0  rd    18699  wr        2
>  xvd 4  8:21 - oo        0  rd    18699  wr        2
> Domain 7 - oo        0  rd      869  wr      376
>  xvd 7  8:22 - oo        0  rd      869  wr      376
> Domain 8 - oo        0  rd      721  wr      197
>  xvd 8  8:23 - oo        0  rd      721  wr      197
> Domain 9 - oo        0  rd      640  wr       77
>  xvd 9  8:24 - oo        0  rd      640  wr       77
>
> The outputs show the following information.
>
> The first line shows domain information.
>      Detail: Domain [Domain ID] - oo [oo-reqs] rd  [rd-reqs] wr [wr-reqs].
Cool! But what is the "oo" and "oo-reqs" in the above line?

Thanks.
H

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, 
>>
>> The first line shows domain information.
>>      Detail: Domain [Domain ID] - oo [oo-reqs] rd  [rd-reqs] wr
[wr-reqs].
>
>Cool! But what is the "oo" and "oo-reqs" in the above
line?
The oo-reqs is counted up in the case that request is blocked for no pending
queues in blkback.
BUt, I don''t know that what does OO stand for.

If oo-req counts up huge amount in short time, so it means that I/O request
is very high load.
Namely, I/O performance of devices will not do I/O requests of VMs(DomUs).

If oo-req is not increased, so it means that I/O performance is enough for
I/O reuests of VMs(DomUs).


Thanks,
Satoshi UCHIDA


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 Jun 2006, at 10:51, Satoshi Uchida wrote:
>
> This patch add /xen/proc/vbd.
> This proc file stores counts of I/O requests for VBD.
> I/O requests is counted for each Domains.
We keep getting complained at for adding stuff to /proc. Shouldn''t this
go under the blkback''s sysfs directory somewhere?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Keir.
>>
>> This patch add /xen/proc/vbd.
>> This proc file stores counts of I/O requests for VBD.
>> I/O requests is counted for each Domains.
>
>We keep getting complained at for adding stuff to /proc. Shouldn''t
this
>go
under the blkback''s sysfs directory somewhere?
>
>  -- Keir
Uom.

In my subjective, currently, procfs is used for representing dynamic
information such as statistical data, and sysfs is used for representing
statical information such as module parameters.
In this case, I think that this I/O information is  former, so information
is put into procfs in this time.
As similar example, ballon infromation exist in procfs.

Is it better that realizing at sysfs?

Thanks,
Satoshi UCHIDA


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Satoshi Uchida wrote:
> Uom.
>
> In my subjective, currently, procfs is used for representing dynamic
> information such as statistical data, and sysfs is used for representing
> statical information such as module parameters.
>   
/proc is for process information.  This stuff definitely belongs in 
sysfs.  It''s analogous to /sys/class/net/eth0/statistics/.
> In this case, I think that this I/O information is  former, so information
> is put into procfs in this time.
> As similar example, ballon infromation exist in procfs.
>   
The balloon driver shouldn''t be using proc.

Regards,

Anthony Liguori
> Is it better that realizing at sysfs?
>
> Thanks,
> Satoshi UCHIDA
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21 Jun 2006, at 12:47, Anthony Liguori wrote:
>> In my subjective, currently, procfs is used for representing dynamic
>> information such as statistical data, and sysfs is used for 
>> representing
>> statical information such as module parameters.
>
> /proc is for process information.  This stuff definitely belongs in 
> sysfs.  It''s analogous to /sys/class/net/eth0/statistics/.
Yes. The patchset looks good and is obviously useful -- we''d like to 
apply it if this gets fixed.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 21 Jun 2006 13:30:34 +0100, Keir Fraser wrote:
> 
> On 21 Jun 2006, at 12:47, Anthony Liguori wrote:
> 
>>> In my subjective, currently, procfs is used for representing
dynamic
>>> information such as statistical data, and sysfs is used for 
>>> representing
>>> statical information such as module parameters.
>>
>> /proc is for process information.  This stuff definitely belongs in 
>> sysfs.  It''s analogous to /sys/class/net/eth0/statistics/.
> 
> Yes. The patchset looks good and is obviously useful -- we''d like
to
> apply it if this gets fixed.
Agreed!  It''s a very common feature request so it''ll be great
to get this
in the tree.  This information is sort of available in
/sys/block/<backend-dev>/stat but it''s not terribly reliable in
my
experience (it''s always zero''s for loop devices IIRC).

These patches are missing Signed-Off-By lines too btw.  When you resubmit,
make sure to include those.

Thanks,

Anthony Liguori
>   -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

I looked at the code, and it seems "oo" stands of "out of",
which
indicates how much we were out of request (Xen supports up to 64
requests in queue)

Few minor comments:
- The variable dom_io_info_wq is unused, should be removed.
- printk("%s: out of memory\n", __FUNCTION__) should be used with
KERN_ERR

I have one question: in your below output:
> Domain 4 - oo        0  rd    18699  wr        2
>  xvd 4  8:21 - oo        0  rd    18699  wr        2
I notice that you output the domid with xvd (4), but in the above
line, we already had that information (Domain 4). So why you need to
show the domid again?

Thanks,
H

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks, Feir and Anthony.
> On 21 Jun 2006, at 12:47, Anthony Liguori wrote:
>
>>> In my subjective, currently, procfs is used for representing
dynamic
>>> information such as statistical data, and sysfs is used for 
>>> representing statical information such as module parameters.
>>
>> /proc is for process information.  This stuff definitely belongs in 
>> sysfs.  It''s analogous to /sys/class/net/eth0/statistics/.
>
>Yes. The patchset looks good and is obviously useful -- we''d like
to apply it if this gets fixed.
>
> -- Keir
It''s OK.
I try to examine and develop transition to sysfs file system.

I may worry that where does information locate in sysfs.
In it case, I confer with you, so please give me nice answer.
Current, I think two pattern.
  1. vbd class create /sysfs/class.
  2. Use vbd-* directory under /sysfs/devices/xen-backend/.
May first idea be appropriate?

In addition,
The one of advantage for our method is to represent total information for
domain.
This mechanism is useful for analysis for each domain I/O or total environments.
In sysfs, I see that Interface connect individual device/module information.
Naturally, it is enough by using xentop, but xentop can not take log file.
If xentop can be redirected to normal file, but it file insert binary code.
Aren''t there any good ideas?

Thanks,
Satoshi UCHIDA



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Jun 2006, at 01:54, Satoshi Uchida wrote:
> I may worry that where does information locate in sysfs.
> In it case, I confer with you, so please give me nice answer.
> Current, I think two pattern.
>   1. vbd class create /sysfs/class.
>   2. Use vbd-* directory under /sysfs/devices/xen-backend/.
> May first idea be appropriate?
I think the info should be placed in the directories you mention in 
(2). If there is a ''block class'' later then the vbd
directories will
symlink to (1) anyway (just as happens for vifs), so you can''t really 
go wrong.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,
> I looked at the code, and it seems "oo" stands of "out
of", which
> indicates how much we were out of request (Xen supports up to 64 
> requests in queue)
Thanks.
It may be correct.
>Few minor comments:
>- The variable dom_io_info_wq is unused, should be removed.
>- printk("%s: out of memory\n", __FUNCTION__) should be used with 
>KERN_ERR
Thanks.
I want to review around these codes.

>I have one question: in your below output:
>
>> Domain 4 - oo        0  rd    18699  wr        2
>>  xvd 4  8:21 - oo        0  rd    18699  wr        2
>
>I notice that you output the domid with xvd (4), but in the above line, we
already had that information (Domain 4).
> So why you need to show the domid again?
VBD processes in domain0 runs as xvd threads.
These threads names "xvd [Domain name] [Major Number]:[Minor Number]".
So, I show same name inelligibly.
In addition, I think that total Information for each domain is added optionally.
Therefore, its informatin is needed in such time.


Thanks,
Satoshi UCHIDA



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel