From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC Patch 1/3] Remove sedf extra, weight, and latency parameter support. Date: Fri, 21 Mar 2014 17:16:52 +0100 Message-ID: <1395418612.13892.155.camel@Solace> References: <1394824400-2796-1-git-send-email-nate.studer@dornerworks.com> <1394824400-2796-2-git-send-email-nate.studer@dornerworks.com> <1395400573.27358.44.camel@kazak.uk.xensource.com> <532C2FCF.105@dornerworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7670592504170710228==" Return-path: In-Reply-To: <532C2FCF.105@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: Nate Studer Cc: Ian Campbell , Xi Sisu , Stefano Stabellini , George Dunlap , Ian Jackson , Robert VanVossen , xen-devel@lists.xen.org, Joshua Whitehead List-Id: xen-devel@lists.xenproject.org --===============7670592504170710228== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K/YL0QYl2J2h1SRxo3/f" --=-K/YL0QYl2J2h1SRxo3/f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2014-03-21 at 08:25 -0400, Nate Studer wrote: > On 3/21/2014 7:16 AM, Ian Campbell wrote: > > If you intend in a future non-RFC version of this series to do somethin= g > > like that then we can follow that path at that time. >=20 > Thanks for the information Ian. >=20 > This is the intention, so we would prefer the LIBXL_HAVE_NEW_SCHED_THING = path. > It seems cleaner. >=20 > We just wanted to make sure that there were no major objections to re-pur= posing > the sedf scheduler before we went too far down that path, and so far we h= ave not > seen anybody step up to defend the sedf scheduler. >=20 Well, TBH, seeing someone standing up to defend it as it is now would have been very surprising, from my point of view. :-) As I said, we really want something that is working, easier to maintain, extensible and more advanced, and I think you're putting efforts in the right direction" simplifying the current implementation is absolutely necessary, given its super-broken status. So, unless someone starts screaming really soon, I'd say "go ahead". The one thing I'd like to see, as I already said, is whether, once we'll have simplified it, and once it will get to enhance it (back), we could collaborate with the RT-Xen people. They already have an EDF scheduler which supports multiple budgetting algorithms, so I'm hoping that we can at least learn from their experience, if not (and let's see why not) borrow/upstream some of their code. If you think it would be useful, I'm up for setting up a call between me, you, Sisu, and everyone hat is interested. Just let me know. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-K/YL0QYl2J2h1SRxo3/f 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.0.22 (GNU/Linux) iEYEABECAAYFAlMsZfQACgkQk4XaBE3IOsS5AACfZfU1yLZQFKLuXFEa+YkyXmiD 4qoAn12NLFQXfU1l+L+7pTBKgHlBBJ6I =3ZR7 -----END PGP SIGNATURE----- --=-K/YL0QYl2J2h1SRxo3/f-- --===============7670592504170710228== 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 --===============7670592504170710228==--