Messages in this thread | | | Date | Mon, 1 Feb 2010 09:08:16 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [patch 1/3] Create spin lock/spin unlock with distinct memory barrier |
| |
* Nick Piggin (npiggin@suse.de) wrote: > On Sun, Jan 31, 2010 at 03:52:55PM -0500, Mathieu Desnoyers wrote: > > Create the primitive family: > > > > spin_lock__no_acquire > > spin_unlock__no_release > > spin_lock_irq__no_acquire > > spin_unlock_irq__no_release > > > > raw_spin_lock__no_acquire > > raw_spin_unlock__no_release > > raw_spin_lock_irq__no_acquire > > raw_spin_unlock_irq__no_release > > > > smp_acquire__after_spin_lock() > > smp_release__before_spin_unlock() > > smp_mb__after_spin_lock() > > smp_mb__before_spin_unlock() > > Wow, someone who likes micro optimising things as much as I do.
:-)
> However, these have the wrong names. > > smp_mb__after_x() means that calling that function after calling x() > will give a smp_mb(), right?
Supposed to.
> > With your functions, this is giving a smp_mb() after calling > x__no_acquire().
Good point.
> > I would suggest maybe just don't bother with the __no_acquire > __no_release variants of spin locks, and stick with the expected > semantics for the new smb_mb__xxx functions. x86 still gets the > full benefit.
Well, most other architectures will get a gain by modifying the spin lock/unlock itself and adding the full memory barriers separately. x86 is a special case here.
> > But, I don't know if this is even worthwhile, given where you are > using it.
Given that it's used to modify the scheduler fast path, I try to keep it as fast as possible. But as you point out later in the thread, we might just consider taking all the rq locks one after another when issuing a sys_membarrier() instead. I did these modifications mostly to please Peter who is concerned about the impact of taking these rq lock very frequently in a DoS scenario (which you appropriately point out would not be the first case in the kernel, and would actually generate a RoS rather than DoS).
Thanks,
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |