|
xen-devel
Re: [Xen-devel] credit vs sedf scheduler
|
Hi,
Can I used vcpu-pin to avoid CPU scheduler
overhead? Suppose I have four CPUs, if I used xm vcpu-pin to fix the mapping of
each physcial CPU to virtual CPU. So credit scheduler will not be
needed.
Liang
----- Original Message -----
Sent: Thursday, November 16, 2006 7:49
AM
Subject: 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
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home