On Thu, Mar 29, 2007 at 09:16:05PM +0900, Atsushi SAKAI wrote: So far I'm really wondering. Basically you have virtualization specific scheduling only if the virtualization mechanism has its own scheduler and that's only the case for Xen at the moment unless I'm mistaken. All others reuse the scheduler of the primary Os directly, and unless you start playing with that scheduler there is nothing really to tune, but those changes affects far more than just purely the virtualization side. How would you map the API you propose with say the linux normal scheduler APIs ? I'm a bit worried if the proposed operations are really only making sense in a setup with the Xen hypervisor. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Mon, Apr 02, 2007 at 04:10:53PM +0900, Atsushi SAKAI wrote: I don't think using structs with explicit members for each schedular parameter is viable over the long term. We have already seen Xen go through 3 different schedulars over the course of 1+1/2 years, each one requiring different parameters. I wouldn't be at all surprised it more changes appear in the next 1+1/2 years because the Xen schedular is really very young/immature at this time. I think it is unavoidable that every impl is going to express the schedular parameters in a completely different way. Thus if we're going to have an API for fetching/updating schedular parameters then I think we need to have a weakly typed system which is extensible to an new arbitrary fields without requiring any API changes. Applications themselves will obviously have to be updated to understand any new schedular types that come along, but as I said before I think this is unavoidable unless we crippled the API to make it look generic. enum { VIR_DOMAIN_SCHED_FIELD_INT, VIR_DOMAIN_SCHED_FIELD_LONG, VIR_DOMAIN_SCHED_FIELD_DOUBLE, VIR_DOMAIN_SCHED_FIELD_BOOLEAN, }; struct virDomainSchedParameter { char field[VIR_DOMAIN SCHED_FIELD_LENGTH] int type; union { int i; long long int l; double d; char b; } value; }; typedef struct virDomainSchedParameter virDomainSchedParameter; And each the API take an array of these eg /* Return schedular type in effect 'sedf', 'credit', 'linux' */ const char *virDomainGetSchedularType(virDomainPtr conn); /* Fetch schedular parameters, caller allocates 'params' field of size 'nparams' */ int virDomainGetSchedularParameters(virDomainPtr dom, virSchedParameter *params, int nparams); /* Change schedular parameters */ int virDomainSetSchedularParameters(virDomainPtr dom, virSchedParameter *params, int nparams); Linux only appears to have 2 schedula parameters at this time - 'priority' and 'type' thje latter being one of FIFO, RR, Other, Batch. 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 -=|

Hi, This patch intends Scheduler related API and its 1/3 of Dan Suggested. It adds scheduler type API for libvirt. Other functions like scheduler parameter show and handle are plan to make. This patch includes "virsh dominfo" can see the scheduler type It can be seen if you type virsh dominfo 0 on Xen(sedf or credit) Other scheduler does not show the scheduler information. Anyway, previous Rich question. src/driver.h has a driver interface and these functions should use typedef. So following function definition is correct. +typedef int + (*virDrvDomainGetSchedInfo) (virDomainPtr domain, Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com&gt; Thanks Atsushi SAKAI

Atsushi SAKAI wrote: [...] Actually there's another point. Can you try out the Xen unified patch + Dan's fixes[1][2] and see if they work for you? I notice that your patch depends on the current libvirt.c "multiple-driver" behaviour. Rich. [1] https://www.redhat.com/archives/libvir-list/2007-March/msg00409.html [2] https://www.redhat.com/archives/libvir-list/2007-April/msg00007.html -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Hi, This patch intends to see and handle scheduler parameters. This is based on ML discussion. This patch just support Xen/Credit for Type/Parameters Xen/SEDF for Type only. And other scheduler is not supported but it will be easy to add it. ===How to use (at commandline)=== virsh schedinfo 0 (to see Type/Parameters) virsh schedinfo 0 --weight 512 (to set weight and to show changed Type/Parameters) virsh schedinfo 0 --cap 50 (to set cap and to show changed Type/Parameters) ===Related to API=== I make API based on Dan's mail. But I have added a little bit changes. 1)virSchedParameter Add Unsigned Int and Unsigned Long Long 2)virDomainGetSchedulerType Add variable to return the number of parameters. This purposes allocate virSchedParameter memory on virsh not in libvirt. ===Others=== 0)xen_unified.c tabspace seems 2, it should be fixed. If needed, I will post it as another patch. Thanks Atsushi SAKAI

Hi, Daniel Thank you for various comments. Anyway I have several questions. 0)Is there any documents about libvirt/python/generator.py? It seems make python bindings from XML API description. 1)PROXY-API seems to be not fully supported to various read (for example vcpuinfo). This is just work is going or it is just a policy Anyway, this issue seems to be another work. I hope someone will do it consistently. If nobody do this, I will do it. And one more, Who attend the XenSummit? I plan to go to the XenSummit. Thanks Atsushi SAKAI Daniel Veillard <veillard(a)redhat.com&gt; wrote:

Hi, I add comments to libvirt.h and libvirt.h.in. This purposes is apibuild.py can correctly generate libvirt-api.xml&libvirt-refs.xml. But if I use "union", apibuild.py does not work and libvirt-api.xml is not included in union case. Is there any good idea? Thanks Atsushi SAKAI Atsushi SAKAI <sakaia(a)jp.fujitsu.com&gt; wrote:

On Mon, Apr 09, 2007 at 04:35:15PM +0900, Atsushi SAKAI wrote: Okay, cool, this gets close to something I should commit, I will probably do this today. yeah we should use the generator, but it may have a problem, I will look Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Atsushi SAKAI wrote: That's actually a mistake on my part. I meant to make it 4 spaces. Will fix ... Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Hi, Rich Thank you for your comments. The purpose for asking is, if I get a comment soon. It will shorten my working for this issue. But finally I read through the code. Anyway, the method for building XML document in libvirt is interesting for me. Thanks Atsushi SAKAI "Richard W.M. Jones" <rjones(a)redhat.com&gt; wrote:

See also: http://www.redhat.com/archives/libvir-list/2007-February/msg00096.html Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)