linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ye Liu <ye.liu@linux.dev>
To: Matthew Wilcox <willy@infradead.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Markus.Elfring@web.de,
	Ye Liu <liuye@kylinos.cn>,
	Sidhartha Kumar <sidhartha.kumar@oracle.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>
Subject: Re: [PATCH v4] mm/page_alloc: Consolidate unlikely handling in page_expected_state
Date: Mon, 31 Mar 2025 20:08:01 +0800	[thread overview]
Message-ID: <8720c775-c0fb-4fbf-a1a8-409fef2b67ad@linux.dev> (raw)
In-Reply-To: <Z-ayTt8o656AkGfz@casper.infradead.org>


在 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?
> 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?

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?

Additionally, I’d like to clarify that my intention in submitting
patches is to improve the project, not to create unnecessary workload
for others. If there’s a better way for me to contribute, please let
me know I'm more than willing to collaborate.                         


Thanks,
 Ye Liu



  reply	other threads:[~2025-03-31 15:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-28  1:47 Ye Liu
2025-03-28  9:44 ` Markus Elfring
2025-03-28 14:29 ` Matthew Wilcox
2025-03-31 12:08   ` Ye Liu [this message]
2025-03-31 12:21     ` [v4] " Markus Elfring
2025-03-31 12:51       ` Ye Liu
2025-03-31 13:15         ` Markus Elfring
2025-03-31 15:53         ` Matthew Wilcox
2025-04-02  2:51           ` Ye Liu
2025-03-31 15:59     ` [PATCH v4] " Matthew Wilcox
2025-04-02  2:49       ` Ye Liu
2025-04-03  3:55         ` Vishal Moola (Oracle)
2025-04-03  5:58           ` Ye Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8720c775-c0fb-4fbf-a1a8-409fef2b67ad@linux.dev \
    --to=ye.liu@linux.dev \
    --cc=Markus.Elfring@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuye@kylinos.cn \
    --cc=sidhartha.kumar@oracle.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox