[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
2015-11-29 11:27 GMT-05:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>: > On Sun, 2015-11-29 at 10:38 -0500, Meng Xu wrote: >> >> >> 2015-11-29 7:46 GMT-05:00 Yu-An(Victor) Chen <chen116@xxxxxxx>: >> > Hi Meng, >> > >> Hi, >> >> > >> > So I will rewrite my setup here again, but this time I shorten the >> > period and budget for RTDS like you suggested: >> > >> Nice! :-) >> >> >> > ----------------------------------------------------------------- >> > ------------------------------------------------------------ >> > >> (I like this line, BTW. :-D) >> > >> > >> > for xen-credit : 2vms (both vm are given 8 vCPUs) sharing 8 cores >> > (cpu 0-7) using credit scheduler(both with weight of 800 and >> > capacity of 400) >> > for xen-rtds: 2 vms (both vm are given 8 vCPUs) sharing 8 cores >> > (cpu0-7) using RTDS (both with period of 4000(4ms) and budget of >> > 2000(2ms))) >> > In both setup, dom0 is using 1 core from cpu 8-15 >> > >> > In both setup: >> > >> > I loaded VM2 with constant running task with total utilization of 4 >> > cores. >> > and in VM1 I run iterations of tasks of total utilization rate of 1 >> > cores, 2 cores, 3 cores, 4 cores, and then record their >> > schedulbility. >> > ----------------------------------------------------------------- >> > ------------------------------------------------------------ >> > >> > So st_jobs_stats for the missed deadline jobs are: >> > >> > trial #1 composed of 2 tasks: total tasks utilization rate = 1 >> > >> > (period, exe, deadline)=(21ms,12.023ms,21ms) -> miss all deadline >> > (period, exe, deadline)=(100ms,37.985ms,100ms) -> no miss >> > >> yes, this is the information I need and we can solve the mystery >> now... >> Let's look at this task: >> (period, exe, deadline)=(21ms,12.023ms,21ms) -> miss all deadline >> Its utilization is 12.023 / 21 ~= 0.5614; >> Your VCPU utilization is only 2ms / 4ms = 0.5 >> So even when this task is pinned to one VCPU, it will still miss >> deadline because it has only one thread. :-) >> > 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. > 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. The worst case for the OS to schedule one task is that all of these VCPUs are released at the same time, are schedulable as early as possible in the first period and scheduled as late as possible in the second period, which will create the largest starvation period to the VM. So in the worst case, you won't be able to schedule a task with utilization U on k VCPUs with utilzation U, no matter how large k is. (Think about that these k VCPUs are always scheduled at the same time.) 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. ;-) To Yu-An, The basic idea is, as Dario mentioned in the previous email, that the configuration of VCPUs are important to provide the schedulability of tasks inside VM. Especially, if you are doing research in RT, you need to (maybe have to) know the RT scheduling theory. :-) > > Is it really the case that you can never schedule tasks with U greater > than the smaller U of the various vCPUs (which seems to me to be what > you're implying)? No. In the worst case, it is. Because the VCPUs are created with the "similar" release time, they may very likely be scheduled concurrently and fall into the so-called "worst case" (which is just worse case for sequential task) in an idle system. > > Anyway... > OK. I can understand... Hope my explanation won't cause more confusion. :-D Best, Meng ----------- 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |