Re: [Xen-devel] credit vs sedf scheduler

["Markus Kremer" <markus314@xxxxxxxxxxxxxx>]

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