From: Qian Cai <cai@lca.pw>
To: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v1] mm/memory_hotplug: don't check the nid in find_(smallest|biggest)_section_pfn
Date: Thu, 28 Nov 2019 10:29:24 -0500 [thread overview]
Message-ID: <687DAE43-C40F-4527-876D-CAC750D150B6@lca.pw> (raw)
In-Reply-To: <c1857505-4565-99c8-d86d-efa6c076312a@redhat.com>
> On Nov 28, 2019, at 9:52 AM, David Hildenbrand <david@redhat.com> wrote:
>
> I also agree that it should not be used for basic functional/compile
> tests (I said "It is a way of giving patches *more* testing."). It
> should not be the only place to test stuff (especially to let somebody
> else do it).
>
> However, sometimes we really have to get additional test coverage via
> linux-next, especially for weird archs/configurations/setups.
>
> ... and if we don't have enough reviewers, it's really hard to get stuff
> upstream.
>
> I wish MM patches would get reviewed more thoroughly.
>
> (If we all make a wish, maybe Santa Clause will listen ;) )
What I don’t understand is that we have an policy prohibiting code churn like code optimization in cold path, but allow those micro cleanup of code. Those cleanup also tend to be unregulated and is subject to personal tastes (for example, your CS teachers may have a different taste from mine). I can understand developers want to have fun, but perhaps there are other playground areas that worth taking more risk?
next prev parent reply other threads:[~2019-11-28 15:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 17:41 [PATCH v1] mm/memory_hotplug: don't check the nid in find_(smallest|biggest)_section_pfn David Hildenbrand
2019-11-27 19:03 ` Qian Cai
2019-11-27 19:05 ` David Hildenbrand
2019-11-27 19:37 ` Qian Cai
2019-11-27 19:52 ` David Hildenbrand
2019-11-27 20:49 ` David Hildenbrand
2019-11-27 22:56 ` Qian Cai
2019-11-28 8:46 ` David Hildenbrand
2019-11-28 13:56 ` Qian Cai
2019-11-28 14:03 ` David Hildenbrand
2019-11-28 14:30 ` Qian Cai
2019-11-28 14:42 ` Michal Hocko
2019-11-28 14:52 ` David Hildenbrand
2019-11-28 15:29 ` Qian Cai [this message]
2019-11-28 15:31 ` David Hildenbrand
2019-11-28 17:31 ` Qian Cai
2019-11-28 15:46 ` Michal Hocko
2019-11-28 17:22 ` Qian Cai
2019-11-28 10:15 ` Michal Hocko
2019-11-28 13:52 ` Oscar Salvador
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=687DAE43-C40F-4527-876D-CAC750D150B6@lca.pw \
--to=cai@lca.pw \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=osalvador@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).