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

                                                                            
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to