From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 3/4] Updated comments/variables to reflect cbs, fixed formatting and confusing comments/variables Date: Sat, 28 Jun 2014 04:09:17 +0200 Message-ID: <1403921357.8515.120.camel@Solace> References: <1402689488-3577-1-git-send-email-josh.whitehead@dornerworks.com> <1402689488-3577-4-git-send-email-josh.whitehead@dornerworks.com> <539ED5F5020000780001A899@mail.emea.novell.com> <539F0D40.4000000@eu.citrix.com> <1403021511.16864.194.camel@Solace> <53AC8F4D.1000601@dornerworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0897554666593517505==" Return-path: In-Reply-To: <53AC8F4D.1000601@dornerworks.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: Joshua Whitehead Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , Robert VanVossen , Xen-devel , Nate Studer , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============0897554666593517505== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/i+3F1lCmVLmd9wP6X8e" --=-/i+3F1lCmVLmd9wP6X8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-06-26 at 17:23 -0400, Joshua Whitehead wrote: > On 6/17/2014 12:11 PM, Dario Faggioli wrote: > > Personally, I'm all for having a really working real-time scheduling > > solution, and you all know that. :-) However, especially considering > > Josh's and Robbie's series, I think I would not remove or rename SEDF, = I > > rather "just" amend the implementation. > > > I'll let George comment on this again, but it sounds like from his e-mail= s that > removing SEDF isn't *that* big of a problem, however as discussed elsewhe= re, > keeping the name and changing the "guts" of it sounds like a better optio= n. >=20 Indeed. > > In future, it would be interesting to introduce more advanced real-time > > scheduling features an capabilities, like the ones coming from RT-Xen > > (and the RT-Xen guys are working on doing that), but I think that can b= e > > done step-by-step, and without any massive renaming or removal. > >=20 > This is another point for splitting the patch as we discussed in the earl= ier > e-mail. Having that separation would give us more flexibility in perhaps > merging and splicing in functionality from others if desired. We haven't= had > the chance to fully review the stuff from Meng/RT-Xen, so we'll have to s= ee > what's applicable, but that could certainly be an option. If we upstream= this > patch series it should be relatively easy to then incrementally add featu= res > from other sources over time and for DornerWorks to maintain the schedule= r in > the future. >=20 I wanted to re-review and look as close as possible to both your and RT-Xen's guys' series, but couldn't today. I'll do this on Monday, and let you know what my feeling is about what we should use as a basis and what should be added on top of that incrementally. > > I'm asking explicitly about the parameters because, although I think > > that most of the changes in this series does not actually call for much > > renaming, at least the 'weight' and, to certain extent the 'extra', > > parameters are a bit difficult to deal with (mostly because they're a > > remnant from when SEDF was meant as a general purpose scheduler too!). > >=20 > Just a quick comment on this - our view of the changes to SEDF is to retu= rn it > to something that's suitable for real-time applications which almost by > definition makes it unsuitable as a general purpose scheduler, it was the > conversion to general purpose that made SEDF so ugly in the first place. = So > there may be things about our changes that may cause problems for someone= trying > to run a normal computer on SEDF but make perfect sense in the > embedded/real-time world. > I have no intention to keep/make SEDF suitable for GP scheduling. I'm well aware of the different needs of the two domains (RT and non-RT) and, in general, I'm no fan of "one scheduler to rule them all" approach, as you may well end up in making everyone really unhappy about the service they get. That being said, there are two reasons for my comments above. For one, have a look at what Linus Torvalds usually says about kernel changes that breaks userspace. Sure, we are not Linux, sure SEDF is already broken, etc., but still I don't think it's nice to completely subvert some user's world (provided there are any users, which may be false, I have to admit). As George said, not breaking the compilation at libxl level is something we really must do. About the functionality, I was not so sure. I'm not so sure yet, but I guess I fundamentally concur with him. On a completely different perspective, as I at least partially already pointed out, 'extra' really looks very similar to your soft to me, and for 'weight', since we're talking about CBS, ever heard of GRUB (not the bootloader: Greedy Reclaiming of Unused Bandwidth) and its further evolution SHRUB. they both are enhanced version of the CBS, where a weight may come handy. Of course, I'm not suggesting rushing to implement those right away, I was just wondering what would be best done, from an interface point of view right now, knowing that we may get to it (i.e., to use 'weight' back, and in a very similar way, _without_ turning back SEDF into a non-RT scheduler!). Anyway, there are more pressing decisions to make right now, I think. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-/i+3F1lCmVLmd9wP6X8e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlOuI80ACgkQk4XaBE3IOsQkZwCfYwbO16RhJygd9PG5VrZ5Y5Pl zk0An35ovfOJVc4x75yrzDA59/YG2DBM =Ckc/ -----END PGP SIGNATURE----- --=-/i+3F1lCmVLmd9wP6X8e-- --===============0897554666593517505== 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 --===============0897554666593517505==--