Re: [PATCH] docs/mm: describe current criteria for enabling split page table lock for PTE tables

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/14/26 11:14, Mike Rapoport wrote:
> On Sat, Jun 13, 2026 at 03:14:47PM -0700, Ethan Nelson-Moore wrote:
>> The mm documentation regarding split page table lock for PTE tables
>> refers to the CONFIG_SPLIT_PTLOCK_CPUS config option, which was
>> superseded by CONFIG_SPLIT_PTE_PTLOCKS in commit 394290cba966 ("mm:
>> turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig
>> options"). Update the documentation to refer to the current option and
>> document the situations in which this feature is not supported.
>>
>> Discovered while searching for CONFIG_* symbols referenced in the
>> kernel but not defined in any Kconfig file.
>>
>> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>> ---
>>  Documentation/mm/split_page_table_lock.rst | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
>> index cc3cd46abd1b..c9d16024543b 100644
>> --- a/Documentation/mm/split_page_table_lock.rst
>> +++ b/Documentation/mm/split_page_table_lock.rst
>> @@ -37,9 +37,12 @@ There are helpers to lock/unlock a table and other accessor functions:
>>   - pmd_lockptr()
>>  	returns pointer to PMD table lock;
>>  
>> -Split page table lock for PTE tables is enabled compile-time if
>> -CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS.
>> -If split lock is disabled, all tables are guarded by mm->page_table_lock.
>> +Split page table lock for PTE tables is enabled compile-time (via
>> +CONFIG_SPLIT_PTE_PTLOCKS) if NR_CPUS is greater than or equal to 4 and an
>> +MMU is being used. However, it is not supported on ARM processors with
>> +virtually indexed, physically tagged caches, PA-RISC processors older than
>> +the PA-8000, or 32-bit SPARC processors. If split lock is disabled, all
> 
> "it is not supported on some architectures" would be enough IMO.

Yeah, we can keep this short.

-- 
Cheers,

David