All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] RFC: Automatically adjust dom0 weight
Date: Fri, 10 Feb 2012 09:31:47 +0100	[thread overview]
Message-ID: <1328862707.2863.57.camel@Solace> (raw)
In-Reply-To: <0aa2ccb5622461801936.1328790671@elijah>


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

On Thu, 2012-02-09 at 12:31 +0000, George Dunlap wrote:
> At the moment, the scheduler treats dom0 the same as any other VM
> for the purposes of accounting.  Since dom0 is really a critical
> piece of infrastructure, and a part of the hypervisor system as a
> whole, it would make more sense to try to give dom0 special rights
> wrt CPU time.
> 
To me, this seems more a sensible configuration than a feature to be
embedded in the scheduler. I agree that dom0 always getting some CPU
time is critical in many ways, but I think the scheduler should provide
effective means for achieving such goal and then it is up to toolstack,
sysadmin, etc, to use them appropriately.

I obviously may be wrong, but I see this as a clear example of
implementing a policy, while we should just provide mechanisms. :-)

> This patch will cause the hypervisor to automatically adjust the
> weight of dom0 such that it should be able to get either enough
> cpu for each of its vcpus, or half of the cpus on the system,
> whichever is less.
> 
That's the point. In fact, I think credit has the proper mechanisms to
affect the CPU time a domain receives, but not in such a way that the
above is achieved, and here's why this needs to be done by modifying he
scheduler (am I wrong?). It's sort of in replacement of a "minimum
guaranteed CPU bandwidth" for a domain mechanism, which maybe is too
complex/not worthwhile to put in place in a generalized fashion.

Just to clarify with an example, in sedf you wouldn't need anything like
this, as you specify exactly the _guaranteed_ CPU bandwidth[*] each vcpu
should be entitled with, i.e., sedf implements the correct mechanism for
enforcing a policy like that one, established by someone else up in the
stack... Then obviously sedf has a whole bunch of limitations, and we
all know it. :-P

Another way of looking at it could be, would user expect that? I mean
seeing dom0's weights dynamically changing? But here I really don't have
the proper backup for providing an answer... :-)

> I'm mostly posting to see what the interest in this kind of approach
> is.  If there is interest, I'll do the work to make it more configurable.
> 
Yes, if we want this, I think it at least should be possible to turn it
on and off (although then the question becomes what the default should
be).

Summarizing, if something not equal, but maybe equally effective, could
be achieved without this (e.g.,
http://wiki.xen.org/wiki/Xen_Best_Practices), I'd be happy not having
it. However, if we think it could be useful and it is configurable
enough, I can live with it. :-)

Regards,
Dario

[*] For current implementation of sedf, that is true. If that scheduler
would ever properly support SMP, it will need some more tweaking to stay
true, or it will just become "a bit less true" :-D

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


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

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

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

      reply	other threads:[~2012-02-10  8:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-09 12:31 [PATCH] RFC: Automatically adjust dom0 weight George Dunlap
2012-02-10  8:31 ` Dario Faggioli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1328862707.2863.57.camel@Solace \
    --to=raistlin@linux.it \
    --cc=george.dunlap@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.