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

[Chris Mason]

On Fri, Oct 30, 2026, at 8:12 AM, Muhammad Usama Anjum wrote:
> On 30/10/2026 11:35 am, David Hildenbrand (Arm) wrote:
>> 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.
>
> Yes, these improvements/regression might be because of code movement and how it
> has affected the run time performance. Most importantly, these results show that
> there isn't any drastic affect on performance. These fixes are good to go.

This schbench configuration is going to be really sensitive to process placement, and it
should be doing all of its memory allocations up front.   I haven't done many schbench
runs on this type of hardware, but I'd agree this result shouldn't indicate a bigger lurking
regression anywhere.

-chris