Re: Question about the ability of credit scheduler to handle I/O and CPU intensive VMs

[Yuehai Xu <yuehaixu@gmail.com>]

> I agree, letting a VM with an interrupt run for a short period of time
> makes sense.  The challenge is to make sure that it can't simply send
> itself interrupts every 50us and get to run 100% of the time. :-)

Do you mean that the real time for a VM to have PCPU is quite
uncertain in the case of 50us? I am not familiar with the code
structure, however, as I remembered, the guest kernel should schedule
I/O related process as soon as the completion of its request. For
example, CFS uses vruntime(the time to have CPU) to select the most
suitable process to schedule, and it is highly possible that I/O
process has less vruntime, which means it should preempt other current
process, and be scheduled immediately.

So, if we try to give a very short period of time, 50us for example,
even only 1/10 has been used, in the guest kernel, the I/O process in
VM should be scheduled and it can continuously dispatch requests, in
that way, the problem of I/O latency might be solved.

I am afraid I don't quite understand "..get to run 100% of the time",
I have tried credit2, but my computer can't boot successfully. I know
it is very very hard to debug the code since capture the error log is
difficult, or by remote serial console? I don't try it yet.

Once we give a very short period of time to VM which is waken up by
I/O event, is it possible that the problem of I/O latency be solved?
or the overhead for this frequent interrupt is too high to do this?
Or, no one has tried to test this idea because of difficult debug?

I appreciate your replay.

Thanks,
Yuehai