[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] full support of setting scheduler parameters on domain creation


  • To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Tue, 22 May 2012 07:43:17 +0200
  • Cc: George Dunlap <dunlapg@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 22 May 2012 05:44:18 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dSw/1udfGt/o2gUtFnJwtSZMmEWQN3o6QLeZf0ZXNaCiBslUahNpMqH4 LOyQoIkQC32KBkTaN4SO+tjFAeOHUGGWTh7uoEfw81wlIZ73V2gTUTfQU XvWy2YQYaf1cr4BjH0eb9uADdlNwvfusih2JL3cnB3hyLgPIRJ9mBktLS FyTIYdDx5QPI1fnOwDgXCej7p196Gnx3sKOa3xoQlbTFWt/2208vB8dBo beuu5Rt5XfuZD/haaZkxu/jRf7Be7;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 05/21/2012 03:53 PM, Ian Campbell wrote:
On Mon, 2012-05-21 at 14:48 +0100, George Dunlap wrote:
On Mon, May 21, 2012 at 2:34 PM, Ian Campbell<Ian.Campbell@xxxxxxxxxx>  wrote:
Hmm. Scheduling parameters are handled in the hypervisor. I don't want to
export the knowledge about semantics to the tools. If this is no problem,
why can't I just set the defaults in the tools and omit asking the
hypervisor for the current settings?
Exporting the idea that 0 is not a valid weight is (IMHO at least)
better than exporting the fact that the default weight is (e.g.) 200 and
hard coding that in multiple places.
I agree.

You could define a symbolic name if that would make you more comfortable
(that would allow us to change the specific value without changing the
API)
That is, as long as the "reasonable value" is the same for all of the
parameters.
I actually meant a symbolic name for the default of each, rather than
one for all of them.

-1 would fit for all parameters. This value is either invalid or "don't care".

I half wonder if having an "init schedule params" function which would
set each value to the default for that value would be useful, or if it
would be overkill.

Of course, if we're doing that, it's only one step further to just
reading the actual scheduler parameters...
I suppose we could make the autogenerated libxl_sched_params_init
instead be a hand-coded thing which actually reads them.

Reading the scheduler parameters would require a new hypervisor interface
(e.g. a new sub-command of XEN_DOMCTL_scheduler_op) which will have to be
implemented by all schedulers supporting parameter changes.

I think this would be the cleanest solution. If this is the way to go, I
can prepare a patch.

BTW: I just discovered the first patch was not complete, as the original
coding to select the scheduler didn't take cpupools into account. It just
selected the default scheduler instead of the cpupool specific one.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.