> > Ok, so here is small explanation and a few examples:
> > xm bvt takes the following arguments:
> > DOM - domain id
> > MCUADV - inverse of weight. Therefore if you want to give more CPU
> > decrease
> > MCUADV
> > WARPBACK - boolean, enables domain to execute before other domains after
> > waking up, decreases lattency, useful for driver domains
> > WARPVALUE - the bigger the value the greater number of domais will be
> > preempted
> > WARPL - if warpback is enabled, limit the time that it is enabled for
> > WARPU - after warping was disabled by WARPL enable it again after WAPRU
> >
> > So if you want 30/70 you can do the following:
> > xm bvt 1 47 0 0 0 0
> > xm bvt 2 20 0 0 0 0
> > (since 47/20 ~= 2.33 and 70/30=2.33)
> > the MCUADV is integer, so in order to increase the granurality you can
> > give
> > bigger values. Only the relative value matters.
>
> This is VERY useful information. I didn't even know WARPBACK was boolean.
> My question relates to cpu_weight parameter. I understand that MCUADV is
> 10 / cpu_weight. This means a cpu_weight of 1 is a BVT MCIADV of 10. but
Yes. It is defined as such in tools/libxc/xc_domain.c you can always change it
there if necessary.
> 20 is 0.5. xm bvt will only accept whole numbers as input, so really for
Right.
> cpu_weight you are limited to use 1 -> 10 only.
Ok, so it breakes down like this:
If you give cpu_weight parameter to xm create (either by defining it in the
config file or supplying it as command line parameter) floating point values
are accepted (so in order to get MCUADV of 20 use 0.5)
In order to change scheduling parameters later you have to use xm bvt call.
Now, xm bvt takes MCUADV as its parameter. So you will type:
xm bvt domID 20 something something something
Note that this is already inversed, and therefore it only accepts integers.
All this is a bit confusing. The reason is that cpu_weight is supposed to work
with all schedulers that support weights. The tools will then translate the
cpu_weight parameter to a scheduler specific parameter(s). Look at the above
mentioned:
tools/libxc/xc_domain.c xc_domain_setcpuweight()
> Does anyone have a good example of BVT values for domain0 to make sure it
> is rarely, if ever, starved for CPU? I guess WARPBACK needs to be turned
> on, but from those examples i'm unsure of proper settings.
BVT will guarantee that it will never be starved (all sane schedulers do
that). But you right - you do want to have dom0 getting cpu quickly after
waking up. To get this to work set WARPBACK to 1, and WARPVALUE to some
positive integer. It would be good if somebody finally did some test how the
WARPVALUE affects the performance (you will find some clues in the paper
given below). It does not make sense to set warp limits. This is just a
mechanism to stop warping domains from using too much CPU, but we trust dom0
not to do it anyway (if you decided to set the limits they are measured in
ns).
Hope this helps.
Gregor
> > You can read more about BVT here:
> > http://citeseer.ist.psu.edu/407687.html
> >
> > Any more questions. I am happy to help.
> >
> > Cheers
> > Gregor
> >
> >
> > --
> > Quidquid latine dictum sit, altum viditur --- Anon
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> > Tool for open source databases. Create drag-&-drop reports. Save time
> > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> > Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
--
Quidquid latine dictum sit, altum viditur --- Anon
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|