linux-kernel - Re: arm64 + ARM64_64K

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 12 Nov 2018 15:22:24 -0600
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Andre Przywara <andre.przywara@....com>
CC:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        <linux-rt-users@...r.kernel.org>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: arm64 + ARM64_64K_PAGES=y



On 11/12/18 8:27 AM, Andre Przywara wrote:
> On Fri, 9 Nov 2018 13:15:47 -0600
> Grygorii Strashko <grygorii.strashko@...com> wrote:
> 
> Hi,
> 
>> On 11/8/18 12:14 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 11/8/18 6:00 AM, Sebastian Andrzej Siewior wrote:
>>>> On 2018-11-06 15:34:55 [-0600], Grygorii Strashko wrote:
>>>>> Hi All,
>>>> Hi,
>>>>   
>>>>> Do anybody tried to use ARM64 RT with 76K pages enabled?
>>>>
>>>> 75 would be an off by one but this :)
>>>
>>> Ops 8-). at least subj is correct.
>>>    
>>>>   
>>>>> My attempt shows that enabling  CONFIG_ARM64_64K_PAGES=y
>>>>> increases latencies by ~30%
> 
> That's not really surprising. Performance on systems using a bigger page
> size granules might have some trade-offs (bigger memory overhead, worse
> cache utilization), so 64K pages might not be really great for your
> particular workload. You would probably need a real performance
> analysis (using perf, for instance) to pinpoint TLB misses as your
> bottleneck.
> 
>>>>> cyclictest -n -m -Sp98 -q -D2m with  =y
>>>>>
>>>>>
>>>>> T: 0 (  772) P:98 I:1000 C: 120000 Min:      7 Act:   13 Avg:
>>>>> 10 Max:      85 T: 1 (  773) P:98 I:1500 C:  79998 Min:      7
>>>>> Act:   13 Avg:   10 Max:      71 T: 2 (  774) P:98 I:2000 C:
>>>>> 59997 Min:      7 Act:   11 Avg:   11 Max:      64 T: 3 (  775)
>>>>> P:98 I:2500 C:  47996 Min:      7 Act:   14 Avg:   12 Max:      66
>>>>>
>>>>>
>>>>> cyclictest -n -m -Sp98 -q -D2m with CONFIG_ARM64_64K_PAGES=n
>>>>>
>>>>>
>>>>> T: 0 (  697) P:98 I:1000 C: 120000 Min:      7 Act:   10 Avg:
>>>>> 9 Max:      38 T: 1 (  698) P:98 I:1500 C:  79987 Min:      7
>>>>> Act:   10 Avg:   10 Max:      32 T: 2 (  699) P:98 I:2000 C:
>>>>> 59981 Min:      7 Act:   14 Avg:   11 Max:      46 T: 3 (  700)
>>>>> P:98 I:2500 C:  47977 Min:      6 Act:   11 Avg:   10 Max:
>>>>> 45
>>>>
>>>> So this is an idle system?
>>>
>>> Yes (in general) - it's collected with systemd, so some daemons are
>>> active.
>>>> The Kconfig help says "faster TLB lookup". Interesting.
>>>> Are the 16k pages in between (latency wise) by any chance?
>>>
>>> I'll try it.
>>
>> no i'll not, at least not fast. with 16k pages enabled I can't boot
>> TI 4.14 kernel
>> -  4.14.71-rt44.
>> No msg in log, just "Starting kernel ..."
> 
> You need a core that actually supports 16K pages (supporting
> certain page size granules is architecturally optional).
>  From the Arm Ltd. cores it's Cortex-A73, A75 or A55, possibly other
> newer ones as well. Cortex-A53, A57 and A72 do not support 16k pages.

Thank a lot for you reply.

-- 
regards,
-grygorii