Lockless uidinfo.

[Jeff Roberson]

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.

Jeff

>
> Better to still do it in case that changes.
>
> Kris
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>