Xen devel - Sep 2006 - [PATCH] Sysfs Interface for balloon driver

Hi.

This patch provides a sysfs interface for the balloon driver.

Currently, the interface for the balloon driver is provided by procfs.
However, I was suggested by Kier and Anthony that procfs should handle  only
process information and other information should be located in sysfs,  when I
made the interface for virtual block devices.

The information for the balloon driver also should be moved to sysfs.
So, I have made a sysfs interface for the balloon driver.

The information for balloon driver is placed in /sys/bus/xen/driver/balloon.
I thought of other locations for the information, such as /sys/class/mem or
/sys/devices/xen, but I finally selected the place because the balloon driver is
similar to the front-end driver.
Please comments about that location.


Example outputs of the sysfs interface of the balloon driver are as follows:

 Example 1.  Show each information

    [root@Dom0 ~]# ls /sys/bus/xen/drivers/
    balloon/  pcifront/ vbd/
    [root@Dom0 ~]# ls /sys/bus/xen/drivers/balloon/
    bind  statistics  unbind
    [root@Dom0 ~]# ls /sys/bus/xen/drivers/balloon/statistics/
    balloon_high  current_pages  hard_limit
    balloon_low   driver_pages   target_pages
    [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_high
          0 kB
    [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_low
       510976 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/current_pages
       262144 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/driver_pages
       1024 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/hard_limit
       ??? kB


 Example 2. Set memory size of a domain

   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/target_pages
     262144 kB
   [root@Dom0 ~]# echo 1024M >
/sys/bus/xen/drivers/balloon/statistics/target_pages
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/target_pages
    1048576 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/current_pages
     758192 kB
   [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/hard_limit
     758192 kB


The information for VMs should be located one place.
I want to propose a new location for the information of VMs, for example:
  /sys/virtualization -+--- domain
                               +--- hypervisor


Regards
Satoshi UCHIDA 
   NEC Corporation, Japan



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

On Wed, Sep 20, 2006 at 09:26:43AM +0900, Satoshi Uchida wrote:
>     [root@Dom0 ~]# cat /sys/bus/xen/drivers/balloon/statistics/balloon_high
>           0 kB
It''s very unusual to have units in a sysfs node. I believe this should
just be the number, and documented elsewhere what the units are.

I also don''t quite get the location. I don''t quite think of
balloon as a
real "driver" as such, it''s core kernel functionality rather.
Wouldn''t
/sys/hypervisor/properties/balloon/ be a more sensible place?

regards,
john

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

Thanks John.
> >     [root@Dom0 ~]# cat 
> /sys/bus/xen/drivers/balloon/statistics/balloon_high
> >           0 kB
> 
> It''s very unusual to have units in a sysfs node. I believe 
> this should just be the number, and documented elsewhere what 
> the units are.
I also hesitated that there give units or not.
First, units are not given.
However, I myself didn''t understand units which is byte? or pages?.
In procfs, It is easy to understand because there have units.
So, in this time, I take them units.

As you say, it should be remove.

> I also don''t quite get the location. I don''t quite think
of
> balloon as a real "driver" as such, it''s core kernel 
> functionality rather. Wouldn''t 
> /sys/hypervisor/properties/balloon/ be a more sensible place?
In this time, it locate by following reason.
  A balloon driver is similar to front-end driver.
   1. It does not handle real device.
       Namely, by virtualization technology,
       it feign to handle computer elements. 
   2. Its computer elements is handled in 
       Domain (VM).
       Namely, it does not handle the whole real environments,
       and Its information is valid for VM.

I feel that the term "hypervisor" means VMM in general.
And a balloon exists for VM, and not for VMM.
Therefore, I think that such information should not be located to
/sys/hypervisor.

Should new location make for storing such (VM''s) information ?
For example, as following.
  /sys/virtualization -+--- domain
                             +--- hypervisor

Tnaks your reply.

Regards
Satoshi UCHIDA 
   NEC Corporation, Japan


> -----Original Message-----
> From: John Levon [mailto:levon@movementarian.org] 
> Sent: Wednesday, September 20, 2006 10:13 AM
> To: Satoshi Uchida
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Sysfs Interface for balloon driver
> 
> On Wed, Sep 20, 2006 at 09:26:43AM +0900, Satoshi Uchida wrote:
> 
> >     [root@Dom0 ~]# cat 
> /sys/bus/xen/drivers/balloon/statistics/balloon_high
> >           0 kB
> 
> It''s very unusual to have units in a sysfs node. I believe 
> this should just be the number, and documented elsewhere what 
> the units are.
> 
> I also don''t quite get the location. I don''t quite think
of
> balloon as a real "driver" as such, it''s core kernel 
> functionality rather. Wouldn''t 
> /sys/hypervisor/properties/balloon/ be a more sensible place?
> 
> regards,
> john
> 

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

On Wed, Sep 20, 2006 at 12:00:36PM +0900, Satoshi Uchida wrote:
> In this time, it locate by following reason.
>   A balloon driver is similar to front-end driver.
Not really. Front-end drivers are real drivers, thus it makes sense for
them to appear to be attached to a bus, even if that bus is virtual.
> I feel that the term "hypervisor" means VMM in general.
> And a balloon exists for VM, and not for VMM.
I don''t understand what you mean here.
> Therefore, I think that such information should not be located to
/sys/hypervisor.
Anyone else have an opinion?
> Should new location make for storing such (VM''s) information ?
> For example, as following.
>   /sys/virtualization -+--- domain
>                              +--- hypervisor
Why would we need this? We already have xenstore for representing other
domain''s information, and /sys/ is always specific to that particular
operating system instantiation.

regards
john

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

John Levon wrote:
>> Therefore, I think that such information should not be located to
/sys/hypervisor.
>>     
>
> Anyone else have an opinion?
>   
I *always* have an opinion :-)

Personally, I think the ballooning information ought to be exposed as a 
module parameter and appear in the sysfs module path.  I''ve always 
thought /sys/hypervisor ought to expose information from the hypervisor.

Regards,

Anthony Liguori
>> Should new location make for storing such (VM''s) information ?
>> For example, as following.
>>   /sys/virtualization -+--- domain
>>                              +--- hypervisor
>>     
>
> Why would we need this? We already have xenstore for representing other
> domain''s information, and /sys/ is always specific to that
particular
> operating system instantiation.
>
> regards
> john
>
> _______________________________________________
> 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

> John Levon wrote:
> >> Therefore, I think that such information should not be located to
> /sys/hypervisor.
> >>
> >
> > Anyone else have an opinion?
> >
> 
> I *always* have an opinion :-)
> 
> Personally, I think the ballooning information ought to be exposed as
a
> module parameter and appear in the sysfs module path.  I''ve always
> thought /sys/hypervisor ought to expose information from the
hypervisor.

I don''t think the memory target stuff is a driver.
''balloon'' should not
appear in the name anyhow -- this stuff is getting ever more closely
integrated with Linux''s core memory management anyhow, it''s
definitely
not a driver.

I sort of slightly buy Anthony''s argument that /sys/hypervisor should
just expose information about the hypervisor.

/sys/devices/system/memory/{target,current,max,..} ?

Ian




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

On Thu, Sep 21, 2006 at 12:23:34AM +0100, Ian Pratt wrote:
> /sys/devices/system/memory/{target,current,max,..} ?
Sounds pretty good to me.

regards
john

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

Ian Pratt wrote:
>> Personally, I think the ballooning information ought to be exposed as
>>     
> a
>   
>> module parameter and appear in the sysfs module path.  I''ve
always
>> thought /sys/hypervisor ought to expose information from the
>>     
> hypervisor.
>
> I don''t think the memory target stuff is a driver.
''balloon'' should not
> appear in the name anyhow -- this stuff is getting ever more closely
> integrated with Linux''s core memory management anyhow,
it''s definitely
> not a driver.
>
> I sort of slightly buy Anthony''s argument that /sys/hypervisor
should
> just expose information about the hypervisor.
>
> /sys/devices/system/memory/{target,current,max,..} ?
>   
Works for me.

Regards,

Anthony Liguori
> Ian
>
>
>
>   

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

Thanks Ian, Anthony, John.
> I don''t think the memory target stuff is a driver.
''balloon''
> should not appear in the name anyhow -- this stuff is getting 
> ever more closely integrated with Linux''s core memory 
> management anyhow, it''s definitely not a driver.
> /sys/devices/system/memory/{target,current,max,..} ?
OK.

> I sort of slightly buy Anthony''s argument that 
> /sys/hypervisor should just expose information about the hypervisor.
I also think such.

However, where should VM (domain) information is located?
Such location will be probably appeared in future.
And, will a reader (or developer) be perplexed at location which needed
information is stored?
Currently, information about virtualization stored sparsely.
Should make a location for gathering such information?

It is important not to make the user conscious which native or VM.
It might be better to store information in general location and to use symlink
for gathering location.
By such reason, balloon information may be better to locate under
/sys/class/mem.


Regards,
Satoshi UCHIDA


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