Hi Naoki,
Thanks for your excellent work.
This days, I tested the playing audio/video with your patches. With the
default credit scheduler, the audio effect is really bad(a lot of audio
glitches). But I got a better result with your patches. I list my findings
here, FYI.
1. What's the latency requirement for audio? I am not good at this
one:) I find some links regarding to it(
http://www.soundonsound.com/sos/jan05/articles/pcmusician.htm and
http://www.podcomplex.com/blog/setting-buffers-and-latency-for-your-audio-interface/).
In native env, setting the buffer size of audio hardware to produce a latency
of 23ms is acceptable even for many musicians. It's safe to say we have to
schedule in the VM for each 23ms for such case in virtual env when playing
audio in VM. Even worse for Vista, which has 10ms requirement (
http://blogs.technet.com/markrussinovich/archive/2007/08/27/1833290.aspx ).
Apparently, the default credit scheduler can't handle well for this case.
2. Test env:
hardware:
Cpu: INTEL Core 2 Duo E6850
Chipset: 82G33
Memory: 2G
software:
Xen upstream(cs: 18881)
doms configuration:
guest A: primary HVM guest(integreted graphic card,
sound, USB controller directly assigned), playing mp3 with WMP in foreground +
copying large files(e.g. 2G) in background. 2 vcpus, 1G memory. Guest OS is
Windows XP or Vista.
guest B: secondary HVM guest(also copying large files
in guest, no devices assigned). 2 vcpus, 128M memory. Guest OS is Windows XP.
3. Configure the scheduler and Xen:
a. the weight of guest B must be lower as much as possible(e.g.
10 for it, but 256 for guest A and dom0). Guest B is competing with Guest A for
dom0. The lower the weight, the lesser chance to be scheduled in.
b. the boost credit needs to be larger as much as possible.(e.g
1000 for both primary guest and dom0). To make sure the guest A stays in boost
priority longer when doing heavy I/O.
c. vcpus of guest A need to be pinned to physical cpu. Without
pinned and guest is smp, the scheduler will dynamically migrate vcpus between
physcial cpus, and the audio glitches is also obvious. One of possible reason
is high freq of migration and the small runtime when the vcpu be scheduled in.
The migration rate is about 60~110 per second, and each migration has the
migration cost(such as cache, TLB miss, etc..). And the runtime is small, 90%
of runtime is less than 30us. It sounds not reasonable to migrate a vcpu, but
it just runs for a tens of microseconds.
With this configuration, both xp/vista guest works well, no glitches
usually.
4. issues left:
a. Abrupt glitches are still generated when the QEMU emulated
mouse being used and moving mouse quickly in guest A. Passing-through USB
mouse/keyboard to guest A, then no glitches.
b. vcpu migration. As said before, without vcpu pinned,
glitches are obvious.
c. the limitation of weight for guest B. I have to set the
weight of guest B to 10. It may not be reasonable in real usage case.
Do you have the experience with audio? I don't know I have properly
configured your scheduler or not. Hope the your scheduler can solve the audio
issues also.
NISHIGUCHI Naoki wrote:
> Hi all,
>
> The patchset is revised version of patches that I was posted 10 days
> ago. This patchset is consist of the following 4 patches.
>
> 1. Subtract credit consumed accurately and shorten cpu time per one
> credit
> 2. Change the handling of credits over upper bound.
> 3. Balance credits of each vcpu of a domain
> 4. Introduce boost credit for latency-sensitive domain
>
> It was not possible to separate these cleanly.
> Please apply these patches in numerical order.
>
> Please review these patches.
> Any comments are appreciated.
>
> Best regards,
> Naoki Nishiguchi
Best Regards,
Disheng, Su
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home