Test result of xen-unstable changeset 25249

Test result of xen-unstable changeset 25249

[Fantu]

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
usb redirection.
-------------------------
/etc/modules
------------
loop max_loop=64
xenfs
xen-evtchn
blktap
-------------------------
hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
25249:a4e7fce6ee2b)
vi Makefile # removed dist-kernel to not compile kernel
-------------------------
Added some patches:
- autoconf: add variable for pass arbitrary options to qemu upstream v3
- tools: Improve make deb
-------------------------
./configure --enable-qemuu-spice --enable-qemuu-usbredir
--enable-qemuu-debug
-------------------------
make deb

-------------------------
Recent regression:
-------------
- CRITICAL - PV domU unable to start, freeze on config parsing, with this
output and nothing else:
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
-------------
- On hvm domU start, domU work also this output on xl create:
libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
range, valid values are within range from 1 to 65535
-------------------------

If you need further details tell me and I will post back


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Thu, 2012-04-26 at 11:26 +0100, Fantu wrote:
> Dom0:
> Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version
> 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and
> usb redirection.
> -------------------------
> /etc/modules
> ------------
> loop max_loop=64
> xenfs
> xen-evtchn
> blktap
> -------------------------
> hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is
> 25249:a4e7fce6ee2b)
> vi Makefile # removed dist-kernel to not compile kernel

xen-unstable.hg hasn't (or shouldn't have been) building a kernel for a
long time -- are you really seeing it do so?

> -------------------------
> Added some patches:
> - autoconf: add variable for pass arbitrary options to qemu upstream v3
> - tools: Improve make deb
> -------------------------
> ./configure --enable-qemuu-spice --enable-qemuu-usbredir
> --enable-qemuu-debug
> -------------------------
> make deb
> 
> -------------------------
> Recent regression:
> -------------
> - CRITICAL - PV domU unable to start, freeze on config parsing, with this
> output and nothing else:
> xl create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg

Can you run with "xl -vvv create"?

What is in lucid.cfg?

> -------------
> - On hvm domU start, domU work also this output on xl create:
> libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of
> range, valid values are within range from 1 to 65535

This is no doubt an issue with 25244:e428eae1838c (CCing author). I
suspect the problem is that you are not setting any scheduler options
but it is unconditionally setting them. I think what it really should be
doing, is reading the current settings, updating those which the user
has specified and writing them back. I'm not sure how best to achieve
that in the libxl api though (CCing some scheduler folks)

> -------------------------
> 
> If you need further details tell me and I will post back
> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Test result of xen-unstable changeset 25249

[Fantu]

Ian Campbell-10 wrote
> 
> Can you run with "xl -vvv create"?
> What is in lucid.cfg?
> 

Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
configuration file used:
-------------------------------
lucid.cfg
---------
name="lucid"
vcpus=2
memory=512
disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
'/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
bootloader = '/usr/bin/pygrub'
-------------------------------

xl -vvv create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda1, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda2 spec.backend=unknown
libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
vdev=xvda2, using backend tap
libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
vdev=xvda1 spec.backend=tap
libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
# And after freeze



--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667398.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Thu, 2012-04-26 at 13:06 +0100, Fantu wrote:
> Ian Campbell-10 wrote
> > 
> > Can you run with "xl -vvv create"?
> > What is in lucid.cfg?
> > 
> 
> Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl
> configuration file used:
> -------------------------------
> lucid.cfg
> ---------
> name="lucid"
> vcpus=2
> memory=512
> disk=['/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw',
> '/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw']
> vif=['bridge=xenbr0']
> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
> bootloader = '/usr/bin/pygrub'
> -------------------------------
> 
> xl -vvv create /etc/xen/lucid.cfg
> Parsing config file /etc/xen/lucid.cfg
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda1, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda2 spec.backend=unknown
> libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend
> phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk
> vdev=xvda2, using backend tap
> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk
> vdev=xvda1 spec.backend=tap
> libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching
> tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap)
> # And after freeze

I coincidentally just saw something like this and it turned out to be
because I needed to set "PYTHON_PREFIX_ARG = --install-layout=deb" in
Config.mk.

What happens if you run "pygrub /mnt/vm/disks/lucid.disk1.xm"?

Ian.

Re: Test result of xen-unstable changeset 25249

[Fantu]

pygrub /mnt/vm/disks/lucid.disk1.xm
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 20, in <module>
    import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Thu, 2012-04-26 at 14:57 +0100, Fantu wrote:
> pygrub /mnt/vm/disks/lucid.disk1.xm
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 20, in <module>
>     import xen.lowlevel.xc
> ImportError: No module named xen.lowlevel.xc

This is the same symptoms as the PYTHON_PREFIX_ARG issue I described.

Ian.

Re: Test result of xen-unstable changeset 25249

[Dieter Bloms]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Hi,

On Thu, Apr 26, Ian Campbell wrote:

> This is no doubt an issue with 25244:e428eae1838c (CCing author). I
> suspect the problem is that you are not setting any scheduler options
> but it is unconditionally setting them. I think what it really should be
> doing, is reading the current settings, updating those which the user
> has specified and writing them back. I'm not sure how best to achieve
> that in the libxl api though (CCing some scheduler folks)

yes, this is an issue with my patch :(
All default values has to be 0, but only for the credit(2) scheduler
cpu_weight must not.
So I made a patch, which set a default of 256 when the cpu_weight isn't set
and credit(2) is used and let it 0 when the scheduler sedf is used.

Please try the attached patch and see if it solve this issue.


-- 
Best regards

  Dieter Bloms

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.

[-- Attachment #2: set_correct_default_credit_weight.diff --]
[-- Type: text/x-diff, Size: 1311 bytes --]

libxl: set correct credit cpu weight, when no one is specified in the config file

all default values have to be set to 0, but for the credit(2) scheduler
cpu_weight has to be 256 by default.
So if the weight isn't given in the confgfile we use 256 for the credit(2)
scheduler and 0 for sedf

Signed-off-by: Dieter Bloms <dieter@bloms.de>

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c246211..ec2e3af 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -62,12 +62,18 @@ int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *s
       ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
       break;
     case LIBXL_SCHEDULER_CREDIT:
-      credit_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       credit_info.cap = scparams->cap;
       ret=libxl_sched_credit_domain_set(ctx, domid, &credit_info);
       break;
     case LIBXL_SCHEDULER_CREDIT2:
-      credit2_info.weight = scparams->weight;
+      if (scparams->weight)
+          credit2_info.weight = scparams->weight;
+      else
+          credit_info.weight = 256;
       ret=libxl_sched_credit2_domain_set(ctx, domid, &credit2_info);
       break;
     default:

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: Test result of xen-unstable changeset 25249

[George Dunlap]

On 27/04/12 09:21, Dieter Bloms wrote:
> yes, this is an issue with my patch :( All default values has to be 0, 
> but only for the credit(2) scheduler cpu_weight must not. So I made a 
> patch, which set a default of 256 when the cpu_weight isn't set and 
> credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> try the attached patch and see if it solve this issue. 
Dieter,

Thanks for the patch.  However, I'd really rather avoid putting 
scheduler defaults in xl if we can at all avoid it.  Defaults should be 
set in one place, and that should be in the scheduling code itself.

I think what we really want to do is is any of the parameters are set, 
after the domain is first created, to read the scheduling parameters for 
the domain (which will be the defaults), change the ones that are set in 
the config file, and then write the whole structure back.  That 
shouldn't be too hard, as libxl__sched_set_params() is called after the 
domain itself is created; the main thing is how to tell 
libxl__sched_set_params() which parameters actually need to be set, and 
which should be left alone.

Are you up for doing that?  If not, I can put it on my to-do list.

Thanks,
  -George

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Fri, 2012-04-27 at 09:44 +0100, George Dunlap wrote:
> On 27/04/12 09:21, Dieter Bloms wrote:
> > yes, this is an issue with my patch :( All default values has to be 0, 
> > but only for the credit(2) scheduler cpu_weight must not. So I made a 
> > patch, which set a default of 256 when the cpu_weight isn't set and 
> > credit(2) is used and let it 0 when the scheduler sedf is used. Please 
> > try the attached patch and see if it solve this issue. 
> Dieter,
> 
> Thanks for the patch.  However, I'd really rather avoid putting 
> scheduler defaults in xl if we can at all avoid it.  Defaults should be 
> set in one place, and that should be in the scheduling code itself.
> 
> I think what we really want to do is is any of the parameters are set, 
> after the domain is first created, to read the scheduling parameters for 
> the domain (which will be the defaults), change the ones that are set in 
> the config file, and then write the whole structure back.  That 
> shouldn't be too hard, as libxl__sched_set_params() is called after the 
> domain itself is created;

I guess the low level libxl_sched_*_params_set should take care of this?

>  the main thing is how to tell 
> libxl__sched_set_params() which parameters actually need to be set, and 
> which should be left alone.

Do all of the fields have a spare discriminating value which could mean
"the default". Ideally it would be zero but it doesn't have to be.
Otherwise we can adjust the libxl API to make one available (usually ~0
or similar), the IDL can express these sorts of concepts (see the uses
of init_val).

It may be appropriate to add a libxl__sched_FOO_domain__setdefaults,
which params_set could call to fully initialise the struct (by calling
get...)

> Are you up for doing that?  If not, I can put it on my to-do list.
> 
> Thanks,
>   -George
> 

Re: Test result of xen-unstable changeset 25249

[Fantu]

About second issue apllying patch seem solved.
About first also with this change:

vi Config.mk
PYTHON_PREFIX_ARG = --install-layout=deb

not work, show different error:
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3

pygrub /mnt/vm/disks/lucid.disk1.xm 
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 822, in <module>
    raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel


--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
> About second issue apllying patch seem solved.
> About first also with this change:
> 
> vi Config.mk
> PYTHON_PREFIX_ARG = --install-layout=deb
> 
> not work, show different error:
> Parsing config file /etc/xen/lucid.cfg
> libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
> -3
> 
> pygrub /mnt/vm/disks/lucid.disk1.xm 
> Traceback (most recent call last):
>   File "/usr/bin/pygrub", line 822, in <module>
>     raise RuntimeError, "Unable to find partition containing kernel"
> RuntimeError: Unable to find partition containing kernel

Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
would cause these sorts of failures.

There is no partition table in lucid.disk1.xm, right? I don't use the
split partition scheme myself so I don't know what state it is in.

What sort of filesystem is on lucid.disk1.xm?

Looking at the history of pygrub I don't see anything of interest which
might potentially have broken it (other than the above libfsimage
issue), changes have been rather few lately. Do you know when it last
worked? If so then doing a bisect (just running pygrub, not booting
guests) might be helpful.

Ian.

> 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Test result of xen-unstable changeset 25249

[Fantu]

Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:
>> About second issue apllying patch seem solved.
>> About first also with this change:
>> 
>> vi Config.mk
>> PYTHON_PREFIX_ARG = --install-layout=deb
>> 
>> not work, show different error:
>> Parsing config file /etc/xen/lucid.cfg
>> libxl: error: libxl_create.c:603:do_domain_create: failed to run
>> bootloader:
>> -3
>> 
>> pygrub /mnt/vm/disks/lucid.disk1.xm 
>> Traceback (most recent call last):
>>   File "/usr/bin/pygrub", line 822, in <module>
>>     raise RuntimeError, "Unable to find partition containing kernel"
>> RuntimeError: Unable to find partition containing kernel
> 
> Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that
> would cause these sorts of failures.
> 
> There is no partition table in lucid.disk1.xm, right? I don't use the
> split partition scheme myself so I don't know what state it is in.
> 
> What sort of filesystem is on lucid.disk1.xm?
> 
> Looking at the history of pygrub I don't see anything of interest which
> might potentially have broken it (other than the above libfsimage
> issue), changes have been rather few lately. Do you know when it last
> worked? If so then doing a bisect (just running pygrub, not booting
> guests) might be helpful.
> 
> Ian.
> 
>> 
>> 
>> --
>> View this message in context:
>> http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
>> Sent from the Xen - Dev mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 

Lucid disk1 is ext4 partition, on old xen-unstable test build was working,
also without change of python prefix, monday I retry with full clean build
and also to latest changeset

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670447.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
> Lucid disk1 is ext4 partition, on old xen-unstable test build was working,

Do you know what changeset that was?

> also without change of python prefix, monday I retry with full clean build
> and also to latest changeset

Re: Test result of xen-unstable changeset 25249

[Fantu]

Ian Campbell-10 wrote
> 
> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>> working,
> 
> Do you know what changeset that was?
> 
>> also without change of python prefix, monday I retry with full clean
>> build
>> and also to latest changeset
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
error.
Last working changeset was 25070, after that I do mainly qemu upstream test.

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675394.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Fantu]

Fantu wrote
> 
> 
> Ian Campbell-10 wrote
>> 
>> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:
>>> Lucid disk1 is ext4 partition, on old xen-unstable test build was
>>> working,
>> 
>> Do you know what changeset that was?
>> 
>>> also without change of python prefix, monday I retry with full clean
>>> build
>>> and also to latest changeset
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@.xen
>> http://lists.xen.org/xen-devel
>> 
> I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same
> error.
> Last working changeset was 25070, after that I do mainly qemu upstream
> test.
> 
I tried also pv-grub but it doesn't working.
xl create /etc/xen/lucid.cfg
Parsing config file /etc/xen/lucid.cfg
xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel:
kernel is not a bzImage: Invalid kernel
Daemon running with PID 2683

--
View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675450.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: Test result of xen-unstable changeset 25249

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2731 bytes --]

On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: 
> > I think what we really want to do is is any of the parameters are set, 
> > after the domain is first created, to read the scheduling parameters for 
> > the domain (which will be the defaults), change the ones that are set in 
> > the config file, and then write the whole structure back.  That 
> > shouldn't be too hard, as libxl__sched_set_params() is called after the 
> > domain itself is created;
> 
> I guess the low level libxl_sched_*_params_set should take care of this?
> 
Possibly, but there's more I'm not sure I understand in the patch (the
original patch, the one that has been checked-in on Wednesday):

+int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl_scheduler sched;
+    libxl_sched_sedf_domain sedf_info;
+    libxl_sched_credit_domain credit_info;
+    libxl_sched_credit2_domain credit2_info;
+    int ret;
+
+    sched = libxl_get_scheduler (ctx);
+    switch (sched) {
+    case LIBXL_SCHEDULER_SEDF:
+      sedf_info.period = scparams->period;
+      sedf_info.slice = scparams->slice;
+      sedf_info.latency = scparams->latency;
+      sedf_info.extratime = scparams->extratime;
+      sedf_info.weight = scparams->weight;
+      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
+      break;
+    case LIBXL_SCHEDULER_CREDIT:
+      credit_info.weight = scparams->weight;
<snip>

sched gets the return value of libxl_get_scheduler() which, if I'm not
wrong , read the "default" xen scheduler for this boot, i.e., the one
specified by the "sched=" boot command line or whatever the default for
that is (credit1).

After that it decides what libxl_sched_*_domain_set() to call basing
right on that value. What I'm missing is what prevents the domain in
question to be part of a cpupool (e.g., by specifying "poolid=" in its
config file as well) for which the scheduler is a different one.

It seems to me that, in such case, we will be setting the wrong set of
parameters anyway, independently on how well we manage in putting a
default in place for them... Am I missing something? If not, as I
haven't found any way of finding out what scheduler is actually being
used for a specific domain, shouldn't we add or mimic that (going
through cpupool, perhaps, I haven't checked yet)?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Fri, 2012-04-27 at 16:20 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: 
> > > I think what we really want to do is is any of the parameters are set, 
> > > after the domain is first created, to read the scheduling parameters for 
> > > the domain (which will be the defaults), change the ones that are set in 
> > > the config file, and then write the whole structure back.  That 
> > > shouldn't be too hard, as libxl__sched_set_params() is called after the 
> > > domain itself is created;
> > 
> > I guess the low level libxl_sched_*_params_set should take care of this?
> > 
> Possibly, but there's more I'm not sure I understand in the patch (the
> original patch, the one that has been checked-in on Wednesday):
> 
> +int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    libxl_scheduler sched;
> +    libxl_sched_sedf_domain sedf_info;
> +    libxl_sched_credit_domain credit_info;
> +    libxl_sched_credit2_domain credit2_info;
> +    int ret;
> +
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      sedf_info.period = scparams->period;
> +      sedf_info.slice = scparams->slice;
> +      sedf_info.latency = scparams->latency;
> +      sedf_info.extratime = scparams->extratime;
> +      sedf_info.weight = scparams->weight;
> +      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      credit_info.weight = scparams->weight;
> <snip>
> 
> sched gets the return value of libxl_get_scheduler() which, if I'm not
> wrong , read the "default" xen scheduler for this boot, i.e., the one
> specified by the "sched=" boot command line or whatever the default for
> that is (credit1).
> 
> After that it decides what libxl_sched_*_domain_set() to call basing
> right on that value. What I'm missing is what prevents the domain in
> question to be part of a cpupool (e.g., by specifying "poolid=" in its
> config file as well) for which the scheduler is a different one.
> 
> It seems to me that, in such case, we will be setting the wrong set of
> parameters anyway, independently on how well we manage in putting a
> default in place for them... Am I missing something? If not, as I
> haven't found any way of finding out what scheduler is actually being
> used for a specific domain, shouldn't we add or mimic that (going
> through cpupool, perhaps, I haven't checked yet)?

I think you are right. Should we have libxl_gfet_domain_scheduler (or
some such) which implements the appropriate logic?

Ian.

Re: Test result of xen-unstable changeset 25249

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1522 bytes --]

On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote: 
> > It seems to me that, in such case, we will be setting the wrong set of
> > parameters anyway, independently on how well we manage in putting a
> > default in place for them... Am I missing something? If not, as I
> > haven't found any way of finding out what scheduler is actually being
> > used for a specific domain, shouldn't we add or mimic that (going
> > through cpupool, perhaps, I haven't checked yet)?
> 
> I think you are right. Should we have libxl_gfet_domain_scheduler (or
> some such) which implements the appropriate logic?
> 
If we want to keep the patch (and I'm sure we want, as having the
possibility to set scheduling parameters in the config file kills a
regression against xm, and it's a very nice feature after all :-D) I
think we should.

I can look into that if you want. I'm also trying to figure out if a
default value for the various parameters of the various scheduler can be
"elected". It doesn't look like an easy thing to do, e.g., consider sedf
wants time values for "period" and "slice", so virtually any unsigned
value is meaningful, although, yes, period=0 or slice=0 barely make
sense, and thus maybe we can use these...

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Test result of xen-unstable changeset 25249

[Ian Campbell]

On Fri, 2012-04-27 at 16:35 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote: 
> > > It seems to me that, in such case, we will be setting the wrong set of
> > > parameters anyway, independently on how well we manage in putting a
> > > default in place for them... Am I missing something? If not, as I
> > > haven't found any way of finding out what scheduler is actually being
> > > used for a specific domain, shouldn't we add or mimic that (going
> > > through cpupool, perhaps, I haven't checked yet)?
> > 
> > I think you are right. Should we have libxl_gfet_domain_scheduler (or
> > some such) which implements the appropriate logic?
> > 
> If we want to keep the patch (and I'm sure we want, as having the
> possibility to set scheduling parameters in the config file kills a
> regression against xm, and it's a very nice feature after all :-D) I
> think we should.
> 
> I can look into that if you want. I'm also trying to figure out if a
> default value for the various parameters of the various scheduler can be
> "elected". It doesn't look like an easy thing to do, e.g., consider sedf
> wants time values for "period" and "slice", so virtually any unsigned
> value is meaningful, although, yes, period=0 or slice=0 barely make
> sense, and thus maybe we can use these...

There's always ~(TYPE)0 for whatever the type is...

Ian.