This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove __is_smp
On 16/10/2016 01:01, Siddhesh Poyarekar wrote:
> On Sunday 16 October 2016 01:49 AM, Florian Weimer wrote:
>> On 10/15/2016 09:44 AM, Siddhesh Poyarekar wrote:
>>> The flag is always set to 1, so there is no longer a point in setting
>>> and checking it.
>>
>> What about the architecture-specific copies of is_smp_system?
>
> Sheesh, I didn't see them somehow, probably because I was searching for
> __is_smp_system :/
>
> I withdraw my patch.
>
> Siddhesh
>
I think we can still proceed with this cleanup, it really seems another
old dubious optimization oriented approach that does not justify the
kind of code complexity id adds.
Basically i686 will set it based on '/proc/sys/kernel/version' output
(with came from kernel config), SH will always set to 0 and any other
system will be 1 (from nptl/smp.h).
It is only used on adaptive mutexes (PTHREAD_MUTEX_ADAPTIVE_NP), which
will avoid the spin and jump to default mutex lock algorithm. It does
seems sense on kernel without SMP support, but I am sceptical about the
gain and usually better for unicore configuration to just avoid
adaptive mutexes.
I would also say with current glibc usage approach (with even embedded
systems being multicore), this 'optimization' seems even superfluous.