Re: [PATCH v4] mm/page_alloc: Consolidate unlikely handling in page_expected_state

[Ye Liu <ye.liu@linux.dev>]

在 2025/3/31 23:59, Matthew Wilcox 写道:
> On Mon, Mar 31, 2025 at 08:08:01PM +0800, Ye Liu wrote:
>> 在 2025/3/28 22:29, Matthew Wilcox 写道:
>>> On Fri, Mar 28, 2025 at 09:47:57AM +0800, Ye Liu wrote:
>>>> Consolidate the handling of unlikely conditions in the 
>>>> page_expected_state() function to reduce code duplication and improve 
>>>> readability.
>>> I don't think this is an equivalent transformation.
>> Could you explain it in detail?
> page_expected_state() is called both at free and alloc.  I think
> the correct behaviour on encountering a HWPOISON page should be
> different at alloc and free, don't you?
In the alloc process, this patch does not modify the code behavior.
Regarding the free process, the if (unlikely(PageHWPoison(page)) && !order)
code handles the case where order is 0. When order is not 0, it does not
matter if __ClearPageBuddy is used to process the last page of the compound
page, because page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; will also clear it.
Is that right?                                                             

>>> Please, stop with these tweaky patches to incredibly sensitive core code.
>>> Fix a problem, or leave it alone.  We are primarily short of reviewer
>>> bandwidth.  You could help with that by reviewing other people's patches.
>>> Sending patches of your own just adds to other people's workload.
>> Thank you for your feedback. I understand the sensitivity of core code
>> and respect the limitations on reviewer bandwidth. However, I believe
>> that reasonable optimizations should not be rejected solely because
>> they involve core code. If an improvement enhances performance,
>> readability, or maintainability without introducing risks, wouldn't
>> it be worth considering for review?
> If it's a reasonable optimisation, absolutely!  But if it's an
> optimisation, it should be accompanied with a benchmark showing an
> improvement.  As far as improving readability, I'm not yet convinced
> that you have the expertise to make that call.  Every change that is
> made invalidates everybody else's mental model of "how this works".
> So all changes carry a cost.  Sometimes that cost is worth paying,
> other times it isn't.
So we need to discuss the technical aspects first, right?
>> Regarding the reviewer shortage, I’d be happy to help by reviewing
>> other patches as well. Could you please share the process for becoming
>> a reviewer? What are the requirements or steps to get involved?
> There is no process!  Choose a patch, read it, think about it.  What
> problems might there be with it?  What may have been overlooked?
> Is the commit message unclear to you, how could it be improved?
> When you're done, send a Reviewed-by: tag (read the kernel process
> documents for the full meaning of that tag).
>
Thanks for your advice, I will try.


Thanks,

Ye