Re: [PATCH v2 00/47] mm: various (urgent?) fixes

[David Hildenbrand (Arm)]

On 10/30/26 12:19, Muhammad Usama Anjum wrote:
> On 29/10/2026 8:32 pm, David Hildenbrand (Arm) wrote:
>> See v1 on details. TL;DR various fixes :)
>>
>> Thanks to everyone for the review! Hoping I can get some more? :)
>>
>> I am planning on picking these myself, moving them to linux-next fairly
>> soon through mm/core.git.
>>
>> ---
>> Changes in v2:
>> - "mm/memfd: check for real shmem inodes before accessing shmem state"
>>  - Call it inode_is_shmem
>> - "mm/truncate: look again if a folio left the mapping"
>>  - Different fix for truncate_inode_pages_range
>>  - Adjust description
>> - "mm/huge_memory: fix zapping migration entries for device-private THPs"
>>  - Move handling in zap_deposited_table
>> - "mm/mmu_gather: fix flushing ranges with 4 GiB or larger"
>>  - Adjust description"
>> - "mm/huge_memory: split huge PUDs when adjusting VMA boundaries"
>>  - Drop split_pud check
>> - Link to v1: https://patch.msgid.link/20261027-fixes_core-v1-0-6f74bec9a5bb@xxxxxxxxxx
> I ran Fastpath, a Linux kernel performance benchmarking framework, on
> this series against mm-stable on aws-m7g.metal. (I) and (R) indicate
> statistically significant improvements and regressions, respectively.
> The results show 10 improvements and 1 regression. Other, unmarked
> percentage changes can be ignored as statistically insignificant. Hence:
> 
> Tested-by: Muhammad Usama Anjum <usama.anjum@xxxxxxx>


Thanks for the results. IIUC it's schbench that shows a possible regression.

I would expect that no changes here really affect performance at all (neither
positively nor negatively).

"mm/huge_memory: fix list corruption when deferred_split_scan() races with
deferred_split_folio()" fixes locking, but I wouldn't assume that this matters
at all for this benchmark.

"fork: take mmap_lock before copying mm_struct" changes locking, but I also fail
to see how that would affect the benchmark.

Maybe some code layout changes just affect some benchmark on some machines?
Because already seeing 10 improvements makes me wonder how that could possibly be.

So I'll move forward with these fixes for now and see if we get more reports and
could identify actual problematic commits.

-- 
Cheers,

David