On 08/30/2010 06:56 PM, Jeremy Fitzhardinge wrote:
On 08/30/2010 12:45 PM, Rik van Riel wrote:
On 08/30/2010 03:20 PM, Peter Zijlstra wrote:
On Mon, 2010-08-30 at 15:17 -0400, Rik van Riel wrote:
When time is accounted as steal time, it is NOT accounted as
to the current process user/system/..., which in turn should
help it in the scheduler.
Am I overlooking something?
Yeah, the scheduler doesn't care about the user/system time accounting
at all... :-)
Uh oh. This would seem like something we'll want to fix
in an architecture independent way, so s390, etc. also
benefit from it.
I can see this being a real problem when the host and guest
OS have the same time slice - which is quite possible since
they may both be the same version of Linux.
Guest 1, alternating between processes A and B, may end up
with process A getting a lot of actual CPU time, and process
B being scheduled in when the VCPU itself is not running...
Yep. I'd been trying to do that with sched_clock games, but that never
worked out.
I think it basically comes down to adding "sched_clock_unstolen()" which
the scheduler can use to measure time a process spends running, and
sched_clock() for measuring sleep times. In the normal case,
sched_clock_unstolen() would be the same as sched_clock().
That requires the host to export (any time the guest is scheduled
in), the amount of CPU time the VCPU thread has used, and the time
the VCPU was scheduled in.
Since the VCPU must be running when it is examining these variables,
it can calculate the additional time (since it was last scheduled)
to account to the task, and remember the currently calculated time
in its own per-vcpu variable, so next time it can get a delta again.
--
All rights reversed
--
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
