Messages in this thread | | | Date | Thu, 6 Sep 2018 13:55:17 -0700 | From | Davidlohr Bueso <> | Subject | Re: [PATCH -next 0/2] fs/epoll: loosen irq safety when possible |
| |
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
>On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote: >> On Fri, 20 Jul 2018, Andrew Morton wrote: > >> >I'm surprised. Is spin_lock_irqsave() significantly more expensive >> >than spin_lock_irq()? Relative to all the other stuff those functions >> >are doing? If so, how come? Some architectural thing makes >> >local_irq_save() much more costly than local_irq_disable()? >> >> For example, if you compare x86 native_restore_fl() to xen_restore_fl(), >> the cost of Xen is much higher. > >Xen is a moot argument. IIRC the point is that POPF (as used by >*irqrestore()) is a very expensive operation because it changes all >flags and thus has very 'difficult' instruction dependencies, killing >the front end reorder and generating a giant bubble in the pipeline. > >Similarly, I suppose PUSHF is an expensive instruction because it needs >all the flags 'stable' and thus needs to wait for a fair number of prior >instructions to retire before it can get on with it. > >Combined the whole PUSHF + POPF is _far_ more expensive than STI + CLI, >because the latter only has dependencies on instructions that muck about >with IF -- not that many.
ack.
In fact it turns out that my Xen numbers for this patch were actually native (popf), and not the xen_restore_fl() as it was using hvm and not paravirt.
Thanks, Davidlohr
| |