[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
On Wed, 2015-12-02 at 11:01 +0000, Ian Campbell wrote: > On Tue, 2015-12-01 at 23:54 -0600, Meng Xu wrote: > > > > What do you guys think which type of information we should include? > > I think there is an important distinction between credit2/credit and > RT > schedulers such as arinc/rtds etc, which is that the former should > just > work out of the box with no tweaking at all whereas the latter in > general > need some sort of "intelligent input/configuration" to even begin > using > them and have GIGO properties wrt their parameters. > Exactly. This is particularly true for the "issues" raised in this thread. In fact, this has all been about 'schedulability'. Well, if you aim at 'schedulability', you (ought to) have the necessary RT background to figure out what it takes to get there. > And AIUI the "intelligent input/configuration" requires some amount > of background in RT scheduling, else you can get pathological results > and think the scheduler and/or Xen is broken. > Yep. > So I think some sort of warning that the RT schedulers do not "just > work" and require one to understand the properties of your workloads > and the schedulers and to feed them non-garbage inputs would be a > useful to people who might otherwise expect to just "xl create" > (maybe with some random inputs to the required settings) and have a > useful result. > Yeah, I guess we can add something like that. I will send a patch. > Having given that warning I don't think some links to some relevant > background RT stuff would be too much info, neither would the > inclusion of some specifics about the specific algorithm. After all > that background and info is critical to being able to run a system > using those schedulers, isn't it? > True, but I'd much rather avoid turning either xl manpage and/or our wiki in a collection of references to real-time scheduling papers! As said in the other mail, I really would try to limit all this, both in terms of numbers and of complexity of the references themselves. 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) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |