[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
Hi, On 20/11/17 15:19, Robin Murphy wrote: On 20/11/17 14:25, Julien Grall wrote: [...]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).+ 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?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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |