[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Disheng,

Thank you for evaluating patches and reporting results.

Su, Disheng wrote:
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 
  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.

Thanks for your information.
I'll see these links.

        2. Test env:
hardware: Cpu: INTEL Core 2 Duo E6850
                        Chipset: 82G33
                        Memory: 2G
                        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 
        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.

I also noticed that. Though I don't know the precise cause, I found that dom0 and guest A would consume largely CPU time (hundreds of milliseconds) in such situation. In this case, the priority of dom0 and guest A falls rapidly, then guest B runs until the priority of dom0 and guest A becomes BOOST. In worst case, it will take about 120ms.

I tried to solve this issue as follows, but the scheduler correctly didn't schedule according to the weight of a domain. - In csched_schedule(), if a vcpu runs over current time slice then the time slice is subtracted from the vcpu's credit.

I think to need investigate deeply.

                b. vcpu migration. As said before, without vcpu pinned, 
glitches are obvious.

I think that this issue would be solved by adding the condition for migrating the vcpu.
e.g. If the vcpu has boost credit, don't migrate the vcpu.

I'll try to test.

                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.

Is copying large files in background on guest A indispensable?
In my test, guest A runs only video playing.
I think that my approach couldn't solve this issue.

        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.

Sorry, I don't have the experience with audio.
But I'll try to reproduce your configuration and investigate.

Naoki Nishiguchi

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 mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.