NISHIGUCHI Naoki wrote:
> Hi Disheng and George,
>
> Disheng, I'm glad to see your work.
>
> George Dunlap wrote:
>> I'd be interested to hear others' opinions.
>
> I think that static priority is useful under some conditions.
> But, as George said, I also think it is harder to configure properly.
> And I'm anxious that it makes credits on non-RT vcpu meaningless.
>
Not exactly, credits still makes sense for non-RT guests, but these guests only
propotionally share the rest of cpu(not used by RT guest) based on their
wieght/credit. If non-RT guest is scheduled in and out, its credit is
substracted as usual. It has the potential that RT guests monopolise the whole
cpu, if we don't have other mechanisms to prevent that.
> I tested your patch in following environment.
>
> CPU: Intel Core2 Quad Q9450
> Chipset: Intel 82Q35
> VM: dom0 (4 vcpus), HVM (4 vcpus)
> Xen: c/s 19426
> HVM:
> RT priority (1)
> pass-through devcies
> PCI graphic board
> Integrated devices(audio, USB controller)
> playing video
>
> With this configuration, HVM does not work well.
> When HVM does not have RT priority, HVM works well.
>
> I think we would need to consider the relationship between static
> priority and credit, handling of dom0 and driver domain, and so on.
>
Thanks for your testing with the patch!
In client virtualization, with static priority, the simplest way is to set the
primary guest and dom0 as the highest priority(can be different priority),
other auxiliary guests as non-RT guest. I think it *should* sovle the
audio/video glitch, I don't test it though. One of issues in this way is that
other non-RT guests may not have enough CPU/thoughput when user is busy in
primary guest(e.g playing video, copying files at the same time).
I remembered that I heard some audio glitches in some cases with your Bcredit
before. Maybe static priority can be helpful but with a somewhat heavy way...
Could you kindly have a test with this configuration?
> Best regards,
> Naoki Nishiguchi
Best Regards,
Disheng, Su
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home