On 19/12/2014 06:25, Zhang, Yang Z wrote: > I see your point. But from performance point, if we can schedule the > vCPU to another PCPU to handle the interrupt, it would helpful. But I > remember current KVM will not schedule the vCPU in run queue (even > though it got preempted) to another pCPU to run(Am I right?). So it > may hard to do it. Yes. If the vCPU is in the run queue, it means it exhausted its quantum. As Feng said, the scheduler can decide to migrate it to another pCPU, or it can decide to leave it runnable but not start it. KVM doesn't try to force the scheduler one way or the other. If the vCPU is I/O bound, it will not exhaust its quantum and will not be preempted. It will block, and the wakeup vector will restart it. I don't think urgent notifications are interesting. If you want to do real time work, pin the vCPU to a physical CPU, and isolate the pCPU with isolcpus. Then the vCPU will always be running. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
