From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Wei Liu <wei.liu@citrix.com>, Meng Xu <mengxu@cis.upenn.edu>
Subject: Re: [PATCH v1 3/3] xl: enable per-VCPU extratime flag for RTDS
Date: Tue, 8 Aug 2017 18:09:36 +0200 [thread overview]
Message-ID: <1502208576.18446.17.camel@citrix.com> (raw)
In-Reply-To: <CAENZ-+=hy8ZWX2aFPP7nAg-Jn1qgZ33pXQt_wMKDeqastF3mXw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3804 bytes --]
On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
> On Sun, Aug 6, 2017 at 12:22 PM, Meng Xu <mengxu@cis.upenn.edu>
> wrote:
> >
> > diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> > index 2c71a9f..88933a4 100644
> > --- a/tools/xl/xl_cmdtable.c
> > +++ b/tools/xl/xl_cmdtable.c
> > @@ -272,12 +272,13 @@ struct cmd_spec cmd_table[] = {
> > { "sched-rtds",
> > &main_sched_rtds, 0, 1,
> > "Get/set rtds scheduler parameters",
> > - "[-d <Domain> [-v[=VCPUID/all]] [-p[=PERIOD]] [-
> > b[=BUDGET]]]",
> > + "[-d <Domain> [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]]
> > [-e[=EXTRATIME]]]",
> > "-d DOMAIN, --domain=DOMAIN Domain to modify\n"
> > "-v VCPUID/all, --vcpuid=VCPUID/all VCPU to modify or
> > output;\n"
> > " Using '-v all' to modify/output all vcpus\n"
> > "-p PERIOD, --period=PERIOD Period (us)\n"
> > "-b BUDGET, --budget=BUDGET Budget (us)\n"
> > + "-e EXTRATIME, --extratime=EXTRATIME EXTRATIME (1=yes,
> > 0=no)\n"
>
> Hi Dario,
>
> I kept the EXTRATIME value for -e option because: (1) it may be more
> intuitive for users; (2) it needs much less code change than the
> input
> style that does not need EXTRATIME value.
>
I'm of the opposite view.
But again, it's tools' people views' that count. :-D
> As to (1), if users want to set some VCPUs with extratime flag set
> and
> some with extratime flag clear, there are two types of input:
> (a) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -e 0 -v 2 -p 10000 -b
> 4000 -e 1 -v 5 -p 10000 -b 4000 -e 0
> (b) xl sched-rtds -d 1 -v 1 -p 10000 -b 4000 -v 2 -p 10000 -b 4000 -e
> 1 -v 5 -p 10000 -b 4000
> I felt that the style (a) is more intuitive and the input commands
> have very static pattern, i.e., each vcpu must have -v -p -b -e
> options set.
>
Exactly, I do think that (b) is indeed a better user interface.
For instance, what if I want to change period and budget of vcpu 1 of
domain 3, _without_ changing whether or not it can use the extra time.
With (a), I don't think I can do that. Or at least, I'd have to either
remember or check what extratime is right now, and pass that same value
explicitly to `xl sched-rtds -d 3 -v 1 ...'.
That does not look super user-friendly to me.
> As to (2), if we go with -e without EXTRATIME, we will have to keep
> track of the vcpu that has no -e option. I thought about this option,
> we can pre-set the extratime value to false when -v option is
> assigned:
> case 'v':
> ...
> extratimes[v_index] = 0;
>
> and set the extratimes[v_index] = 0 when -e is set.
>
Yes, something like that. Or, even better, use its current value.
That would require calling libxl_vcpu_sched_params_get() (or, at times,
libxl_vcpu_sched_params_get_all()), which I assumed you were doing
already, while you apparently don't. Mmm...
> This approach is not very neat in the code: we have to reallocate
> memory for extratimes array when its size is not enough; we also have
> to deal with the special case when -e is set before -v, such as the
> command "xl sched-rtds -p 10000 -b 4000 -e -v 0"
>
Err... sorry, there's code for reallocations in this patch already,
isn't this the case?
Also, it may be me, but I don't understand how this is different from
how -b and -p are dealt with.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.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: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-08-08 16:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-06 16:22 [PATCH v1 0/3] Towards work-conserving RTDS Meng Xu
2017-08-06 16:22 ` [PATCH v1 1/3] xen:rtds: towards work conserving RTDS Meng Xu
2017-08-08 14:57 ` Dario Faggioli
2017-08-08 19:06 ` Meng Xu
2017-08-08 22:52 ` Dario Faggioli
2017-08-08 22:56 ` Meng Xu
2017-08-06 16:22 ` [PATCH v1 2/3] libxl: enable per-VCPU extratime flag for RTDS Meng Xu
2017-08-08 15:37 ` Dario Faggioli
2017-08-06 16:22 ` [PATCH v1 3/3] xl: " Meng Xu
2017-08-07 2:43 ` Meng Xu
2017-08-08 16:09 ` Dario Faggioli [this message]
2017-08-08 19:16 ` Meng Xu
2017-08-08 22:24 ` Dario Faggioli
2017-08-08 22:55 ` Meng Xu
2017-08-09 10:32 ` Dario Faggioli
2017-08-09 17:12 ` Meng Xu
2017-08-08 22:54 ` [PATCH v1 0/3] Towards work-conserving RTDS Dario Faggioli
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=1502208576.18446.17.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=mengxu@cis.upenn.edu \
--cc=wei.liu@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=xumengpanda@gmail.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.