[Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2

["Su, Disheng" <disheng.su@xxxxxxxxx>]

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