RE: [Xen-devel] [RFC] Add static priority into credit scheduler

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

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