|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] credit vs sedf scheduler
Hi Emmanuel, I am currently running the stable XEN 3.0.3 and previously 3.0.1 with the sedf scheduler. A quick test with the credit scheduler of 3.0.3 showed some long delays.
I will try to reproduce the tests with the latest unstable.
How do i enable the scheduler traces?
thanks, Markus
On 11/16/06, Emmanuel Ackaouy <ack@xxxxxxxxxxxxx
> wrote:Hi Markus.
As Atsushi mentioned, if you're using the credit scheduler,
I/O intensive domUs will preempt CPU intensive ones immediately when they become runnable. They will not wait a full time slice. Well, at least this is true with recent xen-unstable. :-)
Also, the "fairness" between domains can be tuned with the per
domain "weight". If you assign twice the weight to domU1 as you do to domU2, domU1 will be allowed to use twice as much CPU resources as domU2 and will preempt domU2 while it is behind this target. If domU1 isn't consuming lots of CPU, its weight
shouldn't matter much though because it will preempt other domains as explained above.
Have you actually tried to run your application with the credit scheduler? Based on your description, I theorize it should work
and would be interested to look at scheduler traces if you encounter any problems.
Keir already addressed the SEDF question. I think soft real time support is a desirable thing. If you actually look at
what the SEDF scheduler does though, it's not always obeying the administrator's orders or doing a very efficient job with simple workloads.
It would be interesting to compare scheduler traces with your SEDF setup and the credit scheduler and see if, how, and why
SEDF might be scheduling things better for you.
There are certainly simple things we could do in credit to improve soft real time guarantees if needed: - make the system default time slice tuneable. - make per domain time-slice tuneable
- introduce strict priority based scheduling (like the current I/O boost but tuneable per domain by the admin) - Use the strict priority mechanism to offer soft real time time-slice and wake-to-run latency best effort guarantees.
We can also fix a number of problems with SEDF and continue maintaining it. In general, the ability to run multiple schedulers is a good thing. On very large hosts, I would even envision running multiple instances of the same scheduler
-- potentially with different configurations -- on different "soft partitions" of the system.
I think it would be very helpful to better understand the workloads we care about by studying scheduler traces. Do
you want to generate some for your workload and share them? Traces for both SEDF and credit running on a recent version of unstable would be the best. If you need help generating these, I'd be happy to help. I'm especially interested to
address any bugs related to an I/O intensive domain not getting ahold of a CPU under 20ms. With a recent build of xen-untable, I think the credit scheduler should make this happen for you a lot quicker than 20ms (more like < 1 ms)!
Cheers, Emmanuel.
On Thu, Nov 16, 2006 at 09:13:39AM +0100, Markus Kremer wrote: > Hi, > i am using XEN on a voice mailbox system. > One domU sends RTP datagrams every 20ms.
> Using the sedf scheduler it is easy to setup a domain which meets this > criteria. > > I am disappointed by the announcement that sedf will be removed from > future releases. > Under credit the time slicing of 30ms and the fairness among the VCPU
> hurts my system. > > Multi core cpus and pinning each VCPU to a real CPU can solve this > problem, but this will waste resources as real time apps/domUs normally > are not CPU intensive.
> > Why will sedf be removed from XEN? > > How will XEN support soft real-time needs in future? > > Was not the idea of having different schedulers the solution? > > regards,
> Markus
> _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx >
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|