Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Robin Murphy <robin.murphy@xxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel