On 29.07.19 13:53, Dario Faggioli wrote:
On Fri, 2019-07-26 at 14:14 +0200, Juergen Gross wrote:
On 26.07.19 13:56, Dario Faggioli wrote:
On Fri, 2019-07-26 at 13:37 +0300, Andrii Anisov wrote:
- How to avoid the absolute top priority of tasklets (what is
obeyed
by all
schedulers so far). Should idle vcpu be scheduled as the
normal
guest vcpus
(through queues, priorities, etc)?
Therefore, even if there wouldn't be any subsystem explicitly
relying
on the current behavior (which should be verified), I think we are
at
high risk of breaking things, if we change.
We'd break things IMO.
Tasklets are sometimes used to perform async actions which can't be
done
in guest vcpu context. Like switching a domain to shadow mode for
L1TF
mitigation, or marshalling all cpus for stop_machine(). You don't
want
to be able to block tasklets, you want them to run as soon as
possible.
Yep, stop-machine was precisely what I had in mind, but as Juergen
says, there's more.
As said, I suggest we defer this problem or, in general, we treat it
outside of this series.
2) you move all these activities out of idle, and in some other
context, and you let idle just do the idling. At that point,
time
accounted to idle will be only actual idle time, as the time it
took to Xen to do all the other things is now accounted to the
new
execution context which is running them.
And here we are coming back to the idea of a "hypervisor domain" I
suggested about 10 years ago and which was rejected at that time...
It's pretty much what Andrii is proposing already, when he says he'd
consider idle_vcpu an 'hypervisor vcpu'. Or at least a naturale
extension of that.
The main difference is its priority and the possibility to allow it to
become blocked.
I don't know what was the occasion for proposing it, and the argument
against it, 10 years ago, so I won't comment on that. :-D
It was in the discussion of my initial submission of cpupools. It was
one alternative thought to solve the continue_hypercall_on_cpu()
problem. In the end that was done via tasklets. :-)
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
