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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d736a5cc-d976-49fd-9f86-0151d4b0a050@csgroup.eu>
Date: Tue, 3 Dec 2024 20:53:44 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, mpe@...erman.id.au,
 linuxppc-dev@...ts.ozlabs.org
Cc: npiggin@...il.com, maddy@...ux.ibm.com, bigeasy@...utronix.de,
 ankur.a.arora@...cle.com, linux-kernel@...r.kernel.org,
 mark.rutland@....com, vschneid@...hat.com, peterz@...radead.org
Subject: Re: [PATCH 2/3] powerpc: support dynamic preemption



Le 01/12/2024 à 20:45, Shrikanth Hegde a écrit :
> 
> 
> On 11/27/24 12:14, Christophe Leroy wrote:
>>
>>
>> Le 25/11/2024 à 05:22, Shrikanth Hegde a écrit :
>>> Once the lazy preemption is supported, it would be desirable to change
>>> the preemption models at runtime. So this change adds support for 
>>> dynamic
>>> preemption using DYNAMIC_KEY.
>>>
>>> In irq-exit to kernel path, use preempt_model_preemptible for decision.
>>> Other way would be using static key based decision. Keeping it
>>> simpler since key based change didn't show performance improvement.
>>
>> What about static_call, wouldn't it improve performance ?
>>
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index 6d6bbd93abab..01c58f5258c9 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -270,6 +270,7 @@ config PPC
>>>       select HAVE_PERF_EVENTS_NMI        if PPC64
>>>       select HAVE_PERF_REGS
>>>       select HAVE_PERF_USER_STACK_DUMP
>>> +    select HAVE_PREEMPT_DYNAMIC_KEY
>>
>> Can you use HAVE_PREEPT_DYNAMIC_CALL instead ? That should be more 
>> performant.
>>
>> I know static calls are not in for PPC64 yet, you can restart from 
>> https://eur01.safelinks.protection.outlook.com/? 
>> url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Flinuxppc- 
>> dev%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C696bf56dcb544f3e49a408dd1240c477%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638686791595217076%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iUwKXhmoU3YgqNI%2Bi7vwi%2Fz4obxMXD0au%2Fclo1m23ng%3D&reserved=0 cover/20221010002957.128276-1-bgray@...ux.ibm.com/ and https:// github.com/linuxppc/issues/issues/416
>>
> 
> Thanks Christophe, I will take a look and understand.
> 
> May be stupid question, do the concerns of arm still valid for ppc64/ 
> ppc32 out-line static calls?

Not sure. Don't know what they call landing pad.

Limited branch range is a limitation for sure, but whatever the method 
when the called function is too far indirect call is required. And on 
powerpc the max distance is 32 Mb which is quite big for a standard 
kernel. Only modules should be concerned, but do we have scheduling code 
in modules ?

CFI I don't know.

Anyway, I resurected the series I sent to implement inline static calls 
on PPC32. I'm sure we can then amplify it to PPC64.


> https://eur01.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220214165216.2231574-6- 
> mark.rutland%40arm.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C696bf56dcb544f3e49a408dd1240c477%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638686791595233955%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8jT7JHp7HgNIwVEEL7gAI8JiDvCFDShI1eIeARWwbVo%3D&reserved=0
> 
> As I understood, that is the reason they went ahead with DYNAMIC_KEY.

In their commit they have comparisons of assembly code. Can you do the 
same for powerpc to get a better picture of what we are talking about ?


Christophe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ