svn commit: r341682 - head/sys/sys

[John Baldwin]

On 12/7/18 10:10 AM, Ian Lepore wrote:
> On Fri, 2018-12-07 at 12:05 +0000, Mateusz Guzik wrote:
>> Author: mjg
>> Date: Fri Dec  7 12:05:11 2018
>> New Revision: 341682
>> URL: https://svnweb.freebsd.org/changeset/base/341682
>>
>> Log:
>>   unr64: use locked variant if not __LP64__
>>   
>>   The current ifdefs are not sufficient to distinguish 32- and 64-
>> bit
>>   variants, which results e.g. in powerpc64 not using atomics.
>>   
>>   While some 32-bit archs provide 64-bit atomics, there is no huge
>> advantage
>>   of using them on these platforms.
>>   
>>   Reported by:	many
>>   Suggested by:	jhb
>>   Sponsored by:	The FreeBSD Foundation
>>
>> Modified:
>>   head/sys/sys/systm.h
>>
>> Modified: head/sys/sys/systm.h
>> =====================================================================
>> =========
>> --- head/sys/sys/systm.h	Fri Dec  7 12:02:31 2018	(r341
>> 681)
>> +++ head/sys/sys/systm.h	Fri Dec  7 12:05:11 2018	(r341
>> 682)
>> @@ -523,7 +523,7 @@ int alloc_unr_specific(struct unrhdr *uh, u_int
>> item);
>>  int alloc_unrl(struct unrhdr *uh);
>>  void free_unr(struct unrhdr *uh, u_int item);
>>  
>> -#if defined(__mips__) || defined(__powerpc__)
>> +#ifndef __LP64__
>>  #define UNR64_LOCKED
>>  #endif
>>  
>>
> 
> This seems like a wholly unsatisfying solution compared to how trivial
> it would be to do something like have each arch's atomic.h set a symbol
> to indicate whether 64-bit atomics are available. Dismissing 32-bit
> arches because you don't perceive performance to be important there
> doesn't seem like a valid argument.

I think you are free to adjust the #ifdef if you find that it actually
makes a difference.  unr lists have been using a mutex on 32-bit architectures
the entire time the API has existed, and I'm not sure you are running -j128
poudriere package builds on a raspberry pi to get the kind of workload where
this lock contention matters.

-- 
John Baldwin