2009/3/23 Su, Disheng <disheng.su@xxxxxxxxx>:
> Glad to know that credit scheduler is being improved.
> If it can improve the latency/real time capabilty with minimal enhancement
> that will be much better:)
I'm still a bit skeptical, but I guess not as much as before. I don't
think it's really the best solution, and I definitely think that
people shouldn't think about this as a *good* solution to
latency-sensitive workloads like video and audio. But it might be
handy to have around as a "quick-fix". If nothing else, client
virtualization (e.g., VMs with audio pass-through) are important, and
since credit2 isn't going to make it into 3.4, something like this
might be a necessary stand-in.
I'd be interested to hear others' opinions.
Regarding the "sleep-for-some-time-and-wake-up" test, I hacked minios
to do simulate this kind of "periodic deadline work" as a part of my
development. (Patch attached.) It will set a timer to go off every
period, and then spin for a given amount of cycles. If it isn't
scheduled for a period, it "drops" work. Every second it reports the
percentage of work completed. Credit1 does absolutely terrible --
completely unfair and unpredictable. A few changes in credit2 allowed
the number of missed deadlines to degrade gracefully, equally across
all VMs, correlated at least with the VM's weight, in a predictable
manner.
If we did include something like this, we would need to make sure that
we couldn't get into a state where misbehaving RT guests locked out
dom0 and any driver domains necessary for dom0 network access. (We
may trust the VMs not to purposely misbehave, but between bugs and
operator error, there's still plenty of room for misbehavior.) I was
looking through the Linux scheduler code, and they seem to have some
limits on RT processes as well, presumably for the same reason.
-George
minios-periodic-work.diff
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|