From mboxrd@z Thu Jan 1 00:00:00 1970 From: Meng Xu Subject: Re: Xen 4.5 development update (July update) Date: Wed, 20 Aug 2014 09:40:36 -0400 Message-ID: References: <20140815172302.2A9FEC33B7@laptop.dumpdata.com> <1408528434.3725.82.camel@Solace.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3532833188219876172==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XK680-0005Vl-MN for xen-devel@lists.xenproject.org; Wed, 20 Aug 2014 13:40:40 +0000 Received: by mail-oa0-f52.google.com with SMTP id o6so6272868oag.25 for ; Wed, 20 Aug 2014 06:40:36 -0700 (PDT) In-Reply-To: <1408528434.3725.82.camel@Solace.lan> 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: Artem Mygaiev , Matt Wilson , Ian Jackson , "dongxiao.xu@intel.com" , "mengxu@cis.upenn.edu" , "feng.wu@intel.com" , "zhigang.x.wang@oracle.com" , Parth Dixit , "Paul.Skentzos@dornerworks.com" , "wency@cn.fujitsu.com" , "rcojocaru@bitdefender.com" , "guijianfeng@cn.fujitsu.com" , "Vijaya.Kumar@caviumnetworks.com" , Stefano Stabellini , Joshua Whitehead , "zoltan.kiss@citrix.com" , Arianna Avanzini , "yang.z.zhang@intel.com" List-Id: xen-devel@lists.xenproject.org --===============3532833188219876172== Content-Type: multipart/alternative; boundary=001a11c361f6b834c305010fbf76 --001a11c361f6b834c305010fbf76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dario, > > > > The "prognosis" is now the likelihood of completion in the 4.5 > > timeframe. > > A bunch of items had moved to the completed phase which is > > fantastic. > > > > none - nothing yet > > fair - still working on it, patches are prototypes or RFC > > ok - patches posted, acting on review > > good - some last minute pieces > > done - all done, might have bugs > > > > > > > > * XenRT (Preemptive Global Earliest Deadline First) (fair) > > RFC patch posted (v2) > > - Meng Xu > > > > > Although it's a RFC patch, the XenRT can actually works well on the > > machines we have. It currently has the preemptive global EDF > > scheduler. The functionalities I'm currently working on is improving > > its performance based on the review of the first version of patches. > > > If this is the case, I think you should drop the RFC tag/status. > > The idea is this: if you are asking the Xen dev community to provide > some feedback on an idea/prototype implementation, then keep the RFC > tag. If you are proposing something for inclusion in upstream Xen and, > at least according to your own opinion, the code you are submitting is > good enough to be included, then you need to drop the RFC tag. > > Then, of course, there will still be reviews, changes will be requested, > new versions, etc., but it's important to mark the difference between > these two phases, as said, by either retaining or dripping the tag. > > Basing on what you're saying (i.e., that you're working on performances > optimizations), on how the last patch series looked and on the comments > you got, I think it would be fine for you to send the next round of > patches as proper v1, rather than "RFC v3", but that's, of course, up to > you. :-) > =E2=80=8BThank you very much for your advice! I will drop the RFC then in t= he next round of patches (this week). Best, Meng =E2=80=8B --=20 ----------- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania --001a11c361f6b834c305010fbf76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = Dario,
=C2= =A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The "prognosis" is now the = likelihood of completion in the 4.5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0timeframe.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A bunch of items had moved to the com= pleted phase which is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fantastic.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0none - nothing yet
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fair - still working on it, patches a= re prototypes or RFC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ok=C2=A0 =C2=A0- patches posted, acti= ng on review
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0good - some last minute pieces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0done - all done, might have bugs
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 XenRT (Preemptive Global Earl= iest Deadline First) (fair)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC patch posted (v2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Meng Xu
>

> Although it's a RFC patch, the XenRT can act= ually works well on the
> machines we have. It currently has the preemptive global EDF
> scheduler. The functionalities I'm currently working on is improvi= ng
> its performance based on the review of the first version of patches. >
If this is the case, I think you should drop the RFC tag/status.

The idea is this: if you are asking the Xen dev community to provide
some feedback on an idea/prototype implementation, then keep the RFC
tag. If you are proposing something for inclusion in upstream Xen and,
at least according to your own opinion, the code you are submitting is
good enough to be included, then you need to drop the RFC tag.

Then, of course, there will still be reviews, changes will be requested, new versions, etc., but it's important to mark the difference between these two phases, as said, by either retaining or dripping the tag.

Basing on what you're saying (i.e., that you're working on performa= nces
optimizations), on how the last patch series looked and on the comments
you got, I think it would be fine for you to send the next round of
patches as proper v1, rather than "RFC v3", but that's, of co= urse, up to
you. :-)

=E2=80=8BThank you very much for your advice! I will d= rop the RFC then in the next round of patches (this week).

Best,

Meng =E2=80=8B

--


-----------
Meng Xu
PhD Student in Computer = and Information Science
University of Pennsylvania
--001a11c361f6b834c305010fbf76-- --===============3532833188219876172== 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 --===============3532833188219876172==--