On 08/04/09 10:33, Peter Zijlstra wrote:
> On Tue, 2009-08-04 at 19:29 +0200, Martin Schwidefsky wrote:
>
>
>>> So its going to split user time into user and guest. Does that really
>>> make sense? For the host kernel it really is just another user process,
>>> no?
>>>
>> The code (at least in parts) is already upstream. Look at the
>> account_guest_time function:
>>
>> static void account_guest_time(struct task_struct *p, cputime_t cputime,
>> cputime_t cputime_scaled)
>> {
>> cputime64_t tmp;
>> struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
>>
>> tmp = cputime_to_cputime64(cputime);
>>
>> /* Add guest time to process. */
>> p->utime = cputime_add(p->utime, cputime);
>> p->utimescaled = cputime_add(p->utimescaled, cputime_scaled);
>> account_group_user_time(p, cputime);
>> p->gtime = cputime_add(p->gtime, cputime);
>>
>> /* Add guest time to cpustat. */
>> cpustat->user = cputime64_add(cpustat->user, tmp);
>> cpustat->guest = cputime64_add(cpustat->guest, tmp);
>> }
>>
>> The cpu time for a guest is added to p->utime AND p->gtime. That is
>> done not to break existing tools that know nothing about guest time.
>> A guest time aware tool can subtract the p->gtime from p->utime to
>> get the time spent by the process outside of the guest context.
>>
>
> But why? How a vcpu anything other than yet another userspace process?
>
Normally a running process can either be accumulating user or system
time. From the host's perspective, the time spent running a vcpu is
more or less a form of system time[*], but the CPU happens to be in an
odd state (for kvm it would be in an actual completely different CPU
mode; for lguest it would just be configured unusually).
[* I think? I assume qemu goes into a syscall for a while to run the
vcpu, then returns to qemu userspace when it needs to handle some
exception ]
I don't see that vcpu time is so particularly distinct from any other
kind of system time that it really needs a whole special form of time
accounting, unless the scheduler is being modified to schedule guests
differently from normal processes. Otherwise it just seems like
something that could be relegated to one of the existing
tracing/benchmarking/profiling mechanisms.
(Full disclosure: these patches are completely irrelevant to Xen.)
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
