Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms

[Meng Xu <xumengpanda@xxxxxxxxx>]

Hi Lars and Dario,

2015-12-01 4:11 GMT-06:00 Lars Kurth <lars.kurth.xen@xxxxxxxxx>:
>
> I wonder whether we need to add some health warnings and recommended 
> background reading to http://wiki.xenproject.org/wiki/RTDS-Based-Scheduler


Maybe we could add some health warning and add a link to this discussion?
Misconfiguration of the system will usually cause performance
degradation, even for the other schedulers, such as ARINC653, credit,
credit2.
What I'm thinking is how much expert information we should expose to
users. Sometimes, exposing too much information may not be so helpful.
Sometimes, more information just  cause more confusion.

What do you guys think which type of information we should include?

Thanks,

Meng


>
>
> Lars
>
> > On 1 Dec 2015, at 08:59, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> >
> > On Sun, 2015-11-29 at 11:44 -0500, Meng Xu wrote:
> >> 2015-11-29 11:27 GMT-05:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> >> :
> >>>
> >>> Mmmm... As I said many times, I don't remember much of all those RT
> >>> schedulability formulas, but, is really that simple?
> >>
> >> Ah, let me clarify...
> >> It is not that simple. ;-) I just simplify it, hoping it can simplify
> >> the problem and highlight the possible reason.
> >>
> > Ok, glad to know I haven't completely lost my mind, or anything like
> > that! :-)
> >
> >>> I mean, if the in-
> >>> guest scheduling algorithm is global (e.g., global-EDF), the task
> >>> could
> >>> migrate, couldn't it?
> >>
> >> Yes. If these partial VCPUs happen to be scheduled "sequentially",
> >> the
> >> OS inside VM can migrate the task and make the task keep running. But
> >> that is not the worst-case for the OS.
> >>
> > Right, I see it now, and (FWIW) I absolutely agree with the worst-case
> > analysis you provided (thanks). I did not get the fact that you were
> > talking about the worst-case, sorry for the noise. :-D
> >
> >> The detailed illustration of the worst case scenario is at Arvind's
> >> paper: http://link.springer.com/article/10.1007%2Fs11241-009-9073-x
> >> My latest journal paper
> >> (http://link.springer.com/article/10.1007%2Fs11241-015-9223-2)
> >> tighten
> >> the resource supply bound function of the MPR model. I believe the
> >> equations are too boring to most of people in the mailing list.
> >>
> >> So let's avoid the complex equations here. ;-)
> >>
> > Thanks for this too! :-)
> >
> > 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)
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
>



-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel