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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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