[PATCH 1/3] x86: Add CPU Vendor ID detection support for Zhaoxin processors
May Shao(BJ-RD)
MayShao@zhaoxin.com
Tue Dec 10 04:49:00 GMT 2019
On 10/12/2019 2:35 am, Florian Weimer wrote:
> * May Shao:
>
>> On 09/12/2019 4:34 pm, Florian Weimer wrote:
>>> * MayShao:
>>>
>>>> + cpu_features->feature[index_arch_Slow_SSE4_2]
>>>> + |= (bit_arch_Slow_SSE4_2
>>>> + | bit_arch_Prefer_MAP_32BIT_EXEC);
>>>
>>> Is the Prefer_MAP_32BIT_EXEC part really correct?
>>
>> As glibc comments for this macro below:
>>
>> "For 64-bit applications, branch prediction performance may be
>> negatively impacted when the target of a branch is more than
>> 4GB away from the branch"
>>
>> We have analyzed this generation of processors and found it have
>> this issue in theory, so we add this flag for it.
>
> I think this flag was added for processors which cannot predict the
> target of indirect calls if it is more than 4 GiB (or was it 2 GiB)
> away from the current program counter.
Yes, Agree!
>>> As discussed recently, it does not have an effect with programs linked
>>> with -z separate-code (the default these days, I think) and PIE.
>>
>> Do you mean the above macro will be ignored if program linked
>> with -z separate-code and PIE?
>
> If it is linked with -z separate-code, it will be ignored because the
> first load segment does not have the execute bit set, so the mmap
> wrapper does not add the MAP_32BIT flag.
>
> With PIE and without -z separate-code, you get worse performance
> because the dynamic loader is mapped at some 0x7f… address, the main
> program is mapped at 0x55…, and all the shared objects will be mapped
> at 0x00… due to MAP_32BIT.
>
>> If it does, is there any harms if keep this macro? thanks a lot!
>
> Yes, I think it's not very useful in its currently implementation and
> should probably be removed.
Got it. Thanks a lot for your detailed explanation.
I will remove it. Do I need to modify and resend the patch set?
> A real fix will need kernel support, to map everything (dynamic
> loader, main program, shared objects) closely together.
Yes, Agree!
保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
More information about the Libc-alpha
mailing list