On 20/11/17 14:25, Julien Grall wrote:
[...]
+ else {
cpu_relax();
Hmmm I now see why you added cpu_relax() at the top. Well, on Xen
cpu_relax is just a barrier. On Linux it is used to yield.
And that bit is worrying me. The Linux code will allow context
switching to another tasks if the code is taking too much time.
Xen is not preemptible, so is it fine?
This is used when consuming the command queue and could be a potential
performance issue if the queue is large. (This is never the case).
I am wondering if we should define a yeild in long run?
As I said before, Xen is not preemptible. In this particular case, there
are spinlock taken by the callers (e.g any function assigning device).
So yield would just make it worst.
The arguments here don't make much sense - the "yield" instruction has
nothing to do with software-level concepts of preemption. It is a hint
to SMT *hardware* that this logical processor is doing nothing useful in
the short term, so it might be a good idea to let other logical
processor(s) have priority over shared execution resources if applicable.
Until SMT CPUs become commonly available, though, it's somewhat of a
moot point and mostly just a future-proofing consideration.
Robin.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
