Re: [PATCH follow-up] mm/thp: Requesting status update on alignment performance configuration

[siddhartha@kenip.in]

On 2025-09-26 00:16, Vlastimil Babka wrote:
> It's rude to send emails with "request read receipt". Lorenzo explained 
> that
> already in a response to your off-list e-mail week ago.
> 
> On 9/25/25 15:54, siddhartha@kenip.in wrote:
>> On 2025-09-02 18:38, siddhartha@kenip.in wrote:
>>> On 2025-08-12 05:20, siddhartha@kenip.in wrote:
>>>> On 2025-08-12 03:44, siddhartha@kenip.in wrote:
>>>>> On 2025-07-28 16:30, Vlastimil Babka wrote:
>>>> **Pseudo-diff of relevant changes:**
>>>> ```diff
>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>>> index abcd1234efgh..ijkl5678mnop 100644
>>>> --- a/mm/huge_memory.c
>>>> +++ b/mm/huge_memory.c
>>>> @@ -102,6 +102,18 @@ static bool __thp_enabled = true;
>>>>  static bool __thp_defrag = true;
>>>> +/* New performance configuration toggle */
>>>> +static bool thp_performance_mode = false;
>>>> +
>>>> +static int __init setup_thp_performance(char *str)
>>>> +{
>>>> +       if (!str)
>>>> +               return 0;
>>>> +       if (!strcmp(str, "on"))
>>>> +               thp_performance_mode = true;
>>>> +       return 1;
>>>> +}
>>>> +__setup("thp_performance=", setup_thp_performance);
>>>> 
>>>>  static inline bool transparent_hugepage_enabled(struct 
>>>> vm_area_struct
>>>> *vma)
>>>>  {
>>>> @@ -245,7 +257,12 @@ static bool hugepage_vma_check(struct
>>>> vm_area_struct *vma,
>>>>         /* Existing allocation checks */
>>>> -       if (khugepaged_always())
>>>> -               return true;
>>>> +       if (thp_performance_mode)
>>>> +               return true; /* Aggressively prefer THP in 
>>>> performance
>>>> mode */
>>>> +       if (khugepaged_always())
>>>> +               return true;
>>>> 
>>>>         /* Rest of allocation logic */
>>>>  }
>>>> 
>>>> Please Note:
>>>> 
>>>> This is a pseudo-diff since my initial work was developed on Intel
>>>> Developer Cloud workloads without a locally cloned copy of the exact
>>>> committed files.
>>>> 
>>>> If there’s interest, I can provide additional benchmark data and
>>>> extend the implementation to expose runtime toggling via
>>>> /sys/kernel/mm/transparent_hugepage/performance.
> 
> Sorry, it's necessary to send a real patch, not a pseudo-patch, 
> including
> the test results in its commit log.
>> I fully understand the complexities around VMA merging, Rik’s earlier
>> patch,
>> and possible regressions noted with cactusBSSN and ebizzy workloads.
>> However,
>> given the continued performance relevance to AI/ML inference 
>> pipelines,
>> I
>> believe further testing and validation would help determine whether 
>> this
>> knob
>> can be safely integrated (or adapted) for wider use.
>> 
>> Could you please share the **current status of testing or review** on
>> this patch?
> 
> We can't test or review a pseudo-patch. It's not even clear to me what 
> it's
> trying to achieve.
> 
>> If there are specific benchmarks, traces, or refinements needed from 
>> my
>> side, I
>> would be happy to assist in generating or providing them.
> 
> You said you saw improvements in some benchmarks, so re-evaluating them 
> on
> current mainline with a real patch would be the way.
> 
>> I greatly appreciate your time and guidance on moving this forward.
>> 
>> Thank you again for your support.
>> 
>> Best regards,
>> Siddhartha Sharma
>> siddhartha@kenip.in

Hello Vlastimil, Lorenzo, and all,

Thank you for your feedback — and apologies for the “read receipt” flag, 
I understand that was inappropriate for the list. My intention was only 
to ensure
my earlier follow-up wasn’t missed, not to be intrusive.

To clarify: my original emails tried to outline observed performance 
behavior when working with OpenVINO-based inference runs. The 
pseudo-diff I shared was
intended to explain the concept, but I now understand that without a 
proper patch against current mainline it’s not actionable for you to 
test or review.

I will rebase my changes onto current mainline and submit a real patch 
so it’s clear exactly what is being modified. That way, any evaluation 
can be based on
real code, not on assumptions or pseudo-code.

Thank you again for pointing this out — I appreciate your patience, and 
I’ll make sure the next iteration is a proper patch submission suitable 
for review.

I have opened a pull request in the openvino GitHub repository which I 
also shared earlier but the guy who is supposed to review it is on a 
sick leave, but I have seen some commits being merged recently so that's 
a good sign. As soon as that's done with the review and I get the 
developer cloud directory where it was originally worked upon, I will 
share all the necessary details and the actual code.

Thanks for your time and support, I really appreciate it!

Best regards,
Siddhartha Sharma