Hello Dario,
On 26.07.19 15:00, Dario Faggioli wrote:
On Fri, 2019-07-26 at 13:37 +0300, Andrii Anisov wrote:
From: Andrii Anisov <andrii_ani...@epam.com>
Currently the idle time is being accounted as a idle vcpu runtime.
This is not entirely correct, because the entity named idle vcpu is
in fact a hypervisor tasks worker. E.g. some softirqs are processed
by the idle vcpu.
That's all very true, and, as discussed both via mail and in person,
I'm all for it.
Thank you for you interest. And I hope to have some productive discussion here.
:)
and that's by hiding real idle
time in the idle_vcpu blocked time metric? :-D :-P
Yes, I do. You should be noticed I told about idle_vcpu renaming in the cover
letter.
So if you treat current idle_vcpu as a hypervisor_vcpu, you will see that
getting it blocked on wait for event strictly match the idle concept.
Jokes apart,
So let it be :)
I see how it is rather easy to do something like this, so
I understand it being done like this in an RFC patch, but I don't think
it's correct.
This is the VERY RFC with the minimal changes to the existing code and adopting
existing approaches.
This topic is really complex and requires wide discussion, so this series is
rather an invitation to the discussion.
And, on an even more general perspective, the fact that the hypervisor,
when scheduling the idle vcpu, runs softirq, tasklets, etc, it's a
generic concept, not an arch specific one. So, we really should find a
way to implement this in common code, not in arch code.
Yes, in terms of this patch, idle_vcpu_runstate_change() better be moved to
common/schedule.c.
Maybe, but I'm just thinking out loud, and I need to think more about
this, we can do things the other way round. I.e., we measure the time
that it takes to run softirq and tasklets, and we subtract it from
idle_vcpu runtime?
In the patch "schedule: account all the hypervisor time to the idle vcpu" I
extend what I think should be accounted for the hypervisor run time. And subtraction
approach will result in more complex code over there.
--
Sincerely,
Andrii Anisov.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
