Hi,
On 20/11/17 15:19, Robin Murphy wrote:
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.
Oh, sorry I thought this could also be used by the software to switch
between thread. Please disregard my comment then.
Until SMT CPUs become commonly available, though, it's somewhat of a
moot point and mostly just a future-proofing consideration.
Robin.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
