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

[David Hildenbrand (Arm)]

On 10/30/26 14:10, Chris Mason wrote:
> 
> 
> On Fri, Oct 30, 2026, at 8:12 AM, Muhammad Usama Anjum wrote:
>> On 30/10/2026 11:35 am, David Hildenbrand (Arm) wrote:
>>>
>>>
>>> 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.

Thanks Chris and Usama!

I'll respin a v3 shortly and get it into -next tomorrow (unless something really
odd sticks out).

-- 
Cheers,

David