Lockless uidinfo.

[John Baldwin]

On Saturday 25 August 2007 06:23:10 pm Jeff Roberson wrote:
> 
> On Fri, 24 Aug 2007, Kris Kennaway wrote:
> 
> > On Fri, Aug 24, 2007 at 04:09:27PM +0200, Pawel Jakub Dawidek wrote:
> >> On Wed, Aug 22, 2007 at 09:02:53PM +0200, Attilio Rao wrote:
> >>> 2007/8/21, Pawel Jakub Dawidek <pjd at freebsd.org>:
> >>>>
> >>>> New patch is here:
> >>>>
> >>>>         http://people.freebsd.org/~pjd/patches/uidinfo_waitfree.patch
> >>>
> >>> ---  sys/ia64/include/atomic.h.orig
> >>> +++  sys/ia64/include/atomic.h
> >>> @@ -370,4 +370,15 @@
> >>>
> >>>  #define	atomic_fetchadd_int		atomic_fetchadd_32
> >>>
> >>> +static __inline u_long
> >>> +atomic_fetchadd_long(volatile u_long *p, u_long v)
> >>> +{
> >>> +	u_long value;
> >>> +
> >>> +	do {
> >>> +		value = *p;
> >>> +	} while (!atomic_cmpset_64(p, value, value + v));
> >>> +	return (value);
> >>> +}
> >>> +
> >>>
> >>> In cycles like those, as you get spinning, I would arrange things in
> >>> order to do a cpu_spinwait(). Like this:
> >>>
> >>> for (;;) {
> >>>         value = *p;
> >>>         if (atomic_cmpset_64(p, value, value + v))
> >>>                 break;
> >>>         cpu_spinwait();
> >>> }
> >>
> >> In this case there is no difference as this is MI ia64 code and
> >> cpu_spinwait() is defined as /* nothing */ there. As a general rule,
> >> this might be a good idea.
> 
> 
> I don't know that these kinds of loops really need cpu_spinwait().  If you 
> consider that the loop condition is only triggered if a single instruction 
> overlaps with another thread and one thread always wins, the number of 
> cases where we restart more than once is negligible.  I believe pjd's test 
> that was artificially constructed to cause as much contention as possible 
> still only saw 30% loop once.
> 
> This is contrasted with spin-wait code where no-one is making any progress 
> while a lock is held.  I think this just adds complexity to the code 
> without any advantage.
> 
> The cpu_spinwait() function is meant to stop one HTT core from starving 
> another that is holding a lock.  In this case there is no lock and so 
> there is no starvation possible.  Actually by spinwaiting you may increase 
> the chance for a second loop.

Agreed.  cpu_spinwait() is for when we know we will have to wait at least for
a little while.

-- 
John Baldwin