Re: Is guest OS oriented scheduling welcome?

[Avi Kivity <avi@redhat.com>]

刘志建 wrote:
> Hello folks,
> In the past, it was said KVM would like to treat the guest OS threads differently in scheduling. However, till now, the qemu thread is regarded as a conventional user thread. Therefore, it is hard to control how much CPU slices one guest OS can utilize. I don't think a computing cloud provider likes this idea.
> And, what's more, "Xen and Co.: Communication-aware CPU Scheduling for Consolidated Xen-based Hosting Platforms"(http://www.cse.psu.edu/~sgovinda/papers/vee07.pdf) has shown that the standard thread scheduling in Linux might not fit the virtualization environment well.
> I have ported Xen's credit scheduler to KVM.

Do you mean, to KVM, or to the Linux scheduler?

>  With my work, the users can control how much CPU a guest OS can occupy.
> The principles are:
> 1. all the vcpu threads are declared as FIFO RealTime threads;
> 2. before a vcpu thread enters guest mode, its blackboard is checked first, to see if the scheduler wants it to continue. If the vcpu thread has a bad luck, it will give up cpu and waits for permission.
> 3. there is a per-cpu scheduler, which is triggered periodically by its timer. The scheduler writes the scheduling results to the interested party's blackboards. To those that get the permission, the scheduler will try to wake them up in case of their sleeping. 
> 4. In order to port Xen's scheduler, the host Linux is treated as a virtual machine too. However, it never checks its blackboard.
> 5. a user level per-VM credit control mechanism is implemented, to allow users to dynamically adjust a virtual machine's CPU quota.
> Although a vcpu might continue to run for a while after the scheduler has decided that it should actually yield the cpu, our experiments show that this brings trival influence.
> The interaction-oriented scheduling are going to be ported/developed.
>
> If KVM welcomes this function, I will post it out.
>

I think this is very interesting, but should be integrated with the 
Linux scheduler, so it could apply to normal processes, and so it can 
account for host mode, not just guest mode.

-- 
error compiling committee.c: too many arguments to function