linux-kernel - Re: [PATCH v2 4/4] arm64: add a new document for the fine-tuning tips

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]

Message-ID: <e7cbafd4-506b-4e26-ad88-e1afba06e972@amperemail.onmicrosoft.com>
Date: Fri, 6 Dec 2024 14:14:26 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Anshuman Khandual <anshuman.khandual@....com>,
 Huang Shijie <shijie@...amperecomputing.com>, catalin.marinas@....com,
 will@...nel.org
Cc: patches@...erecomputing.com, paulmck@...nel.org,
 akpm@...ux-foundation.org, thuth@...hat.com, rostedt@...dmis.org,
 xiongwei.song@...driver.com, ardb@...nel.org, steven.price@....com,
 suzuki.poulose@....com, mark.rutland@....com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 cl@...amperecomputing.com
Subject: Re: [PATCH v2 4/4] arm64: add a new document for the fine-tuning tips


On 2024/12/6 11:56, Anshuman Khandual wrote:
> On 11/26/24 14:26, Huang Shijie wrote:
>> Put some fine-tuning tips in this file:
>> 	1.) rodata=noalias
>> 	2.) slab_strict_numa
>> 	3.) CONFIG_SCHED_CLUSTER
>>
>> We can add more tips in future.
>>
>> Signed-off-by: Huang Shijie <shijie@...amperecomputing.com>
>> ---
>>   Documentation/arch/arm64/fine-tuning-tips.rst | 23 +++++++++++++++++++
>>   Documentation/arch/arm64/index.rst            |  1 +
>>   2 files changed, 24 insertions(+)
>>   create mode 100644 Documentation/arch/arm64/fine-tuning-tips.rst
>>
>> diff --git a/Documentation/arch/arm64/fine-tuning-tips.rst b/Documentation/arch/arm64/fine-tuning-tips.rst
>> new file mode 100644
>> index 000000000000..70ef1cef92fb
>> --- /dev/null
>> +++ b/Documentation/arch/arm64/fine-tuning-tips.rst
>> @@ -0,0 +1,23 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +================
>> +fine-tuning tips
>> +================
>> +
>> +This file contains some fine-tuning tips for arm64 machines.
>> +These tips do not gurantee that you can get better performance,
>> +but you can try them with your workload.
>> +
>> +rodata=noalias
>> +----------------
>> +It can provide us more block mappings and contiguous hits
>> +to map the linear region which minimizes the TLB footprint.
>> +
>> +slab_strict_numa
>> +----------------
>> +In NUMA, it will provide the local memory allocation by SLUB.
>> +
>> +CONFIG_SCHED_CLUSTER
>> +----------------
>> +Some arm64 machines have cpu core cluster, enable it may
>> +helps you get better performance.
>> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
>> index 6a012c98bdcd..36d1ef09bd71 100644
>> --- a/Documentation/arch/arm64/index.rst
>> +++ b/Documentation/arch/arm64/index.rst
>> @@ -16,6 +16,7 @@ ARM64 Architecture
>>       cpu-feature-registers
>>       cpu-hotplug
>>       elf_hwcaps
>> +    fine-tuning-tips
>>       gcs
>>       hugetlbpage
>>       kdump
> Although the idea for such a file makes sense, to help system admins
> tune the kernel command line for required behaviour, I am concerned
This file also contains the CONFIG_SCHED_CLUSTER which is not a kernel 
command line.
> about the overall structure and scope for such a document. Should it
> contain tips regarding all the subsystems on the platform, till what
> extent these details should be described in there and then there are
> so many aspects for a required behaviour etc ?

My original thought is to let this file contains the tips only works in 
arm64.

All the tips which _may_ make the arm64 machines get better performance 
can be

recorded here.

Then the arm64 kernel engineers(the newbies) can follow this file, and 
ramp up

quickly.


>
> Besides maintaining such a document might also be very difficult as
> well given how implementations will change over time thus requiring
> different tuning etc. Hence kernel source might not be a place for
> such a document.

okay. If the kernel source is not the right place, I can remove this 
patch in next version.


Thanks

Huang Shijie