This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/3] x86: Add CPU Vendor ID detection support for Zhaoxin processors
- From: "May Shao(BJ-RD)" <MayShao at zhaoxin dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "carlos at redhat dot com" <carlos at redhat dot com>, "Cooper Yan(BJ-RD)" <CooperYan at zhaoxin dot com>, "Qiyuan Wang(BJ-RD)" <QiyuanWang at zhaoxin dot com>, "Herry Yang(BJ-RD)" <HerryYang at zhaoxin dot com>, "Ricky Li(BJ-RD)" <RickyLi at zhaoxin dot com>
- Date: Tue, 10 Dec 2019 04:49:12 +0000
- Subject: Re: [PATCH 1/3] x86: Add CPU Vendor ID detection support for Zhaoxin processors
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.