From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC] [Design] Better XL support of RTDS scheduler for Xen 4.6 Date: Tue, 24 Feb 2015 14:16:18 +0000 Message-ID: <1424787378.27930.352.camel@citrix.com> References: <20150223155724.GB20083@zion.uk.xensource.com> <1424774243.27930.310.camel@citrix.com> <1424775147.4742.56.camel@citrix.com> <1424775992.27930.319.camel@citrix.com> <1424777420.4742.78.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YQGIK-0008Ny-A6 for xen-devel@lists.xenproject.org; Tue, 24 Feb 2015 14:17:04 +0000 In-Reply-To: <1424777420.4742.78.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Wei Liu , "xen-devel@lists.xenproject.org" , "xisisu@gmail.com" , "chaowang@wustl.edu" , George Dunlap , "lu.wustl@gmail.com" , "sokolsky@cis.upenn.edu" , "linhphan@cis.upenn.edu" , "xumengpanda@gmail.com" , "cdgill@cse.wustl.edu" , Ian Jackson , "lichong659@gmail.com" , "lee@cis.upenn.edu" , "dgolomb@seas.upenn.edu" , "mengxu@cis.upenn.edu" List-Id: xen-devel@lists.xenproject.org On Tue, 2015-02-24 at 11:30 +0000, Dario Faggioli wrote: > The problem is whether or not we allow overlap, i.e., whether the same > parameters can live in both interfaces, and what is the semantic of > that. Ah, I see. > Let's take RTDS as an example. budget and period make sense at the vcpu > level so, as soon as we introduce the API for per-vcpu params, they > should live there. But then what about the budget and period field we > have in libxl_domain_sched_params? What's the meaning of them? > Semantically speaking, they just should be killed. OTOH, what I was > suggesting was this: if one calls libxl_domain_sched_params_set(), which > takes a libxl_domain_sched_params, the budget and priod there will be > interpreted as "for the whole domain", and applied to all the domain's > vcpus. It's in this sense that I see it an either/or: > - at domain creation time, if the user does not say anything we'll use > the domain-wide API for setting a default budget and period for all > the vcpus. > - if the user does say something in the config file (once this will be > possible), or upon request, via the proper xl command, to modify the > parameters of vcpu X, we'll use the vcpu-wide API. The simplest (and IMHO least surprising) thing would be to have the per-vcpu ones override the per-domain ones. IOW per-domain sets a default used unless a per-vcpu one says otherwise for a given vcpu. So at build time you would first call the per-domain set function with whatever parameters were provided, followed by setting any per-vcpu options which are configured. At run time via xl commands I guess they would be separate commands for domains vs vcpus, and if you call the per-domain one I'd probably expect it to clobber any existing per-vcpu settings (i.e act like the vcpu option given --all). > Of course this applies to parameters that are part of both > structs/interfaces, which is something I was thinking to allow... were > you? Yes, I think it makes sense to have them. Ian.