From mboxrd@z Thu Jan 1 00:00:00 1970 From: Meng Xu Subject: Re: [PATCH v1 1/4] xen: add real time scheduler rt Date: Fri, 29 Aug 2014 15:35:58 -0400 Message-ID: References: <1408921125-21470-1-git-send-email-mengxu@cis.upenn.edu> <1408921125-21470-2-git-send-email-mengxu@cis.upenn.edu> <53FCB571020000780002DAB7@mail.emea.novell.com> <53FD963B020000780002DED0@mail.emea.novell.com> <53FE0FA7020000780002E224@mail.emea.novell.com> <54005E82020000780002EFB1@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2742655936769921605==" Return-path: In-Reply-To: <54005E82020000780002EFB1@mail.emea.novell.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: Jan Beulich Cc: Ian Campbell , Sisu Xi , Stefano Stabellini , George Dunlap , Chenyang Lu , Dario Faggioli , Ian Jackson , "xen-devel@lists.xen.org" , Linh Thi Xuan Phan , Meng Xu , Chao Wang , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============2742655936769921605== Content-Type: multipart/alternative; boundary=089e013a13262fb0ac0501c9c377 --089e013a13262fb0ac0501c9c377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jan, 2014-08-29 5:05 GMT-04:00 Jan Beulich : > >>> On 28.08.14 at 18:06, wrote: > > =E2=80=8BAs to your concern "I still don't see why such wouldn't be > > applicable uniformly to all schedulers."=E2=80=8B, are you suggesting t= hat the > > credit and credit2 scheduler could also allow users to set/get each > VCPU's > > parameters? (I think that could be possible but this should be some > design > > decision made by credit and credit2 scheduler developer?) > > Perhaps. But I think a more uniform interface to the individual > schedulers would help on the tools side too. But in the end I'm > just raising questions/concerns here, it's George who needs to > be okay with your approach. > =E2=80=8BThank you very much for your questions and suggestions! BTW, the ARINC653 scheduler in Xen also specifies each VCPU's parameters. It's just FYI. :-) In xen/include/public/sysctl.h, it specifies each vcpu's parameter in sched_entries array. /* * This structure is used to pass a new ARINC653 schedule from a * privileged domain (ie dom0) to Xen. */ struct xen_sysctl_arinc653_schedule { /* major_frame holds the time for the new schedule's major frame * in nanoseconds. */ uint64_aligned_t major_frame; /* num_sched_entries holds how many of the entries in the * sched_entries[] array are valid. */ uint8_t num_sched_entries; /* The sched_entries array holds the actual schedule entries. */ struct { /* dom_handle must match a domain's UUID */ xen_domain_handle_t dom_handle; /* If a domain has multiple VCPUs, vcpu_id specifies which one * this schedule entry applies to. It should be set to 0 if * there is only one VCPU for the domain. */ unsigned int vcpu_id; /* runtime specifies the amount of time that should be allocated * to this VCPU per major frame. It is specified in nanoseconds */ uint64_aligned_t runtime; } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDULE]; }; > > >> I think anything going into the seconds, not to speak of minutes or > >> hours, range is already beyond boundaries of being reasonable / > >> useful. > > > > =E2=80=8BHmm, that's fair. If we want to limit the range to seconds, th= en uint32 > is > > enough. However, what if some user really want to set the period/budget > to > > hours/days? Then we couldn't support it if we use uint32 type for > > period/budget. (This is just my subtle concern. I'm not arguing that we > > have to use uint64 or uint32. As long as everyone agrees with a type, I > can > > just change it to the agreed type very quickly.) Do you have any > suggestion > > of how we can reach an agreement and get the range finalized? =E2=80=8B > > Let's see what others, mainly George and Dario, think. > =E2=80=8BSure! Thanks! Meng=E2=80=8B --=20 ----------- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania --089e013a13262fb0ac0501c9c377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = Jan,


201= 4-08-29 5:05 GMT-04:00 Jan Beulich <JBeulich@suse.com>:
>>> On 28.08.14 at 18:06, <xumengpanda@gmail.com> wrote:<= br> > =E2=80=8BAs to your concern "I still don't see why such would= n't be
> applicable uniformly to all schedulers."=E2=80=8B, are you sugges= ting that the
> credit and credit2 scheduler could also allow users to set/get each VC= PU's
> parameters? (I think that could be possible but this should be some de= sign
> decision made by credit and credit2 scheduler developer?)

Perhaps. But I think a more uniform interface to the individual
schedulers would help on the tools side too. But in the end I'm
just raising questions/concerns here, it's George who needs to
be okay with your approach.

=E2=80=8BThank you very much for your questions and sugg= estions!=C2=A0

BTW, the ARINC653 scheduler in Xen also specifies each VCPU= 9;s parameters. It's just FYI. :-)

In=C2= =A0xen/include/public/sysctl.h, it specifies each vcpu's parameter in s= ched_entries array.

/*

=C2=A0* This structure is used to pass a new ARINC653 schedul= e from a

=C2=A0* privileged domain (ie dom0) to Xen.

=C2=A0*/

struct xen_sysctl_arinc653_schedule {=

=C2=A0 =C2=A0 /* major_frame holds th= e time for the new schedule's major frame

=C2=A0=C2=A0 =C2=A0 * in nanoseconds. */

=C2=A0 =C2=A0 uint64_aligned_t =C2=A0 =C2=A0 major_frame;

=C2=A0 =C2=A0 /* num_sched_entries ho= lds how many of the entries in the

=C2=A0=C2=A0 =C2=A0 * sched_entries[] array are valid. */

=C2=A0 =C2=A0 uint8_t =C2=A0 =C2=A0 n= um_sched_entries;

=C2=A0 =C2=A0 /* The sched_entries ar= ray holds the actual schedule entries. */

=C2=A0 =C2=A0 struct {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* dom_ha= ndle must match a domain's UUID */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 xen_domain_handle_t dom_handle;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If a d= omain has multiple VCPUs, vcpu_id specifies which one

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 * this schedule entry appli= es to. It should be set to 0 if

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 * there is only one VCPU fo= r the domain. */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 unsigned = int vcpu_id;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* runtim= e specifies the amount of time that should be allocated

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 * to this VCPU per major fr= ame. It is specified in nanoseconds */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64_aligned_t runtime;

=C2=A0 =C2=A0 } sched_entries[ARINC653_MAX_DOMAINS_PER_SCHEDU= LE];

};

=C2=A0

>> I think anything going into the seconds, not to speak of minutes o= r
>> hours, range is already beyond boundaries of being reasonable / >> useful.
>
> =E2=80=8BHmm, that's fair. If we want to limit the range to second= s, then uint32 is
> enough. However, what if some user really want to set the period/budge= t to
> hours/days? Then we couldn't support it if we use uint32 type for<= br> > period/budget. (This is just my subtle concern. I'm not arguing th= at we
> have to use uint64 or uint32. As long as everyone agrees with a type, = I can
> just change it to the agreed type very quickly.) Do you have any sugge= stion
> of how we can reach an agreement and get the range finalized? =E2=80= =8B

Let's see what others, mainly George and Dario, think.

=E2=80=8BSure! Thanks!

Meng=E2=80= =8B


--


---= --------
Meng Xu
PhD Student in Computer and Information Science
U= niversity of Pennsylvania
--089e013a13262fb0ac0501c9c377-- --===============2742655936769921605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2742655936769921605==--