This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Andi Kleen <ak at linux dot intel dot com>
- Cc: David Brown <david dot brown at hesbynett dot no>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Development <gcc at gcc dot gnu dot org>, Li Bin <huawei dot libin at huawei dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>
- Date: Thu, 4 Jun 2015 23:30:20 +0800
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org> <55701E26 dot 5050503 at hesbynett dot no> <20150604151748 dot GT1187 at tassilo dot jf dot intel dot com>
On Thu, Jun 4, 2015 at 11:17 PM, Andi Kleen <ak@linux.intel.com> wrote:
>> Rather than just a sequence of NOP's, should the first NOP be a
>> unconditional branch to the beginning of the real function? I don't
>> know if this applies to AArch64 cpus, but I believe some cpus can handle
>> such branches already in the decode unit, thus avoiding any extra cycles
>> for skipping the NOPs.
>
> nops are very cheap. Typically they are already discard in the frontend.
> It's unlikely all of this is worth it.
Maybe on Intel's chip but not for an example on ThunderX they are not
discarded. But we can issue 2 at a time. So what is a few cycles
overhead for each function when an icache miss is much higher.
Thanks,
Andrew