[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8D6F4343-89AD-46A3-B7E7-15B8591CB020@caviumnetworks.com>
Date: Mon, 5 Oct 2015 21:00:33 +0000
From: "Pinski, Andrew" <Andrew.Pinski@...iumnetworks.com>
To: Catalin Marinas <catalin.marinas@....com>
CC: "Kapoor, Prasun" <Prasun.Kapoor@...iumnetworks.com>,
Arnd Bergmann <arnd@...db.de>,
"yury.norov@...il.com" <yury.norov@...il.com>,
"Norov, Yuri" <Yuri.Norov@...iumnetworks.com>,
"agraf@...e.de" <agraf@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"klimov.linux@...il.com" <klimov.linux@...il.com>,
"bamvor.zhangjian@...wei.com" <bamvor.zhangjian@...wei.com>,
"apinski@...ium.com" <apinski@...ium.com>,
"philipp.tomsich@...obroma-systems.com"
<philipp.tomsich@...obroma-systems.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"christoph.muellner@...obroma-systems.com"
<christoph.muellner@...obroma-systems.com>,
"pinskia@...il.com" <pinskia@...il.com>
Subject: Re: [PATCH v5 00/23] ILP32 for ARM64
> On Oct 5, 2015, at 8:59 AM, Catalin Marinas <catalin.marinas@....com> wrote:
>
>> On Sat, Oct 03, 2015 at 02:18:57AM +0000, Kapoor, Prasun wrote:
>>> On 10/2/15, 2:37 AM, "Catalin Marinas" <catalin.marinas@....com> wrote:
>>> So, at the time, following x32 discussions, we thought of using the
>>> native ABI as much as possible. However, two important things happened
>>> since:
>>>
>>> 1. libc community didn't like breaking the POSIX compliance
>>> 2. No-one seems desperate for ILP32 on AArch64
>>>
>>> (1) is a fair point and I would rather be careful as we don't know the
>>> extent of the code affected. In the meantime, we've also had ongoing
>>> work for addressing the 2038 issue on 32-bit architectures.
>>>
>>> The second point is equally important. The benchmarks I've seen didn't
>>> show a significant improvement and the messages I got on various
>>> channels pretty much labeled ILP32 as a transitional stage to full LP64.
>>> In this case, we need to balance the benefits of a close to native ABI
>>> (future proof, slightly higher performance) vs. the cost of maintaining
>>> such ABI in the kernel on the long term, especially if it's not widely
>>> used/tested.
>>
>> For us ILP32 is not about putting this into our product flier at all, it
>> is about supporting real applications. We have an existing product line of
>> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
>> applications are currently in production. Our customers are looking to
>> bring those applications (mostly in Networking and Telecom space) over to
>> ARMv8.
>>
>> We think its an extremely risky strategy to say either future processors
>> should incur the additional cost (power and complexity) of implementing
>> Aarch32 instruction set or have no way of supporting 32 bit applications
>> at all.
>
> Well, given that Cavium posted only 3 versions of this series since
> September 2013, it doesn't seem critical at all.
We are going to post another version as soon as we finish the changes that you requested this time around. I am working on the glibc and yury (with my help) will doing the kernel side.
>
>> Apart from there being an installed base of 32 bit networking and telecom
>> applications, we have also seen non-trivial performance gains with ILP32
>> (for example, our SPECINT score goes up by 7% with ILP32 compared to
>> LP64).
>
> It would be good to re-run the benchmarks with the latest gcc since
> LP64/AArch64 support has evolved in the meantime.
We are also rerunning the numbers with the latest released gcc (5.2) and will report results when we submit the next version of the patch set.
Thanks,
Andrew
>
> --
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists