[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



Hi,

2015-11-23 11:35 GMT-05:00 Yu-An(Victor) Chen <chen116@xxxxxxx>:
> Hi Meng,
>
> Thank you very much for replying!
>
> The RT tasks I am running for each trial at a certain utilization rate is a
> collection of real-time tasks, and each real-time task is a sequence of jobs
> that are released periodically. All jobs are periodic, where each job is
> defined by a period (and deadline) and a worse-case execution time. Each job
> is just running of a number of iterations of floating point operations. This
> is based on the base task.c provided with the LITMUSRT userspace library. So
> Yes they are independent and not I/O or memory intensive.

Ah, I see. Which version of LITMUSRT did you use? LITMUS^RT has a bug
in Xen environment. The IPI interrupt is not handled properly in
LITMUS on Xen.  With the bug, the system performance is worse than
when the system is loaded, because LITMUS scheduler just fails to
respond due to the IPI ignorance.

IIRC, this bug was fixed in the latest LITMUSRT code.
Did you use the latest LITMUS code?

One way to debug the issue is:
Can you enable the TRACE in LITMUS and collact the scheduling log in
the scenario when you see the bad performance?

>
> The period distribution I have for each task is (10ms,100ms) which is bigger
> than the VM period I specified using xl sched-rtds (10000us), but I guess
> the lower bound is too close to the VM period. So by your suggestion, maybe
> shorten the period for VM can improve the performance?

Yes. At least it shorten the starvation interval.

Meng

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.