linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Oscar Salvador <osalvador@suse.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, x86@kernel.org,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	Alexander Potapenko <glider@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Borislav Petkov <bp@alien8.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Ira Weiny <ira.weiny@intel.com>, Jason Gunthorpe <jgg@ziepe.ca>,
	Jun Yao <yaojun8558363@gmail.com>,
	Logan Gunthorpe <logang@deltatee.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Pankaj Gupta <pagupta@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	Pavel Tatashin <pavel.tatashin@microsoft.com>,
	Peter Zijlstra <peterz@infradead.org>, Qian Cai <cai@lca.pw>,
	Rich Felker <dalias@libc.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Tony Luck <tony.luck@intel.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Wei Yang <richard.weiyang@gmail.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Will Deacon <will@kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Yu Zhao <yuzhao@google.com>
Subject: Re: [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory
Date: Fri, 31 Jan 2020 11:36:52 +0100	[thread overview]
Message-ID: <c1758220-14c8-2f0f-7fd3-68da0fc9bf94@redhat.com> (raw)
In-Reply-To: <20200131100341.GB24244@dhcp22.suse.cz>

>>> The first patch has reviews, the remainder are unloved.
>>
>> Trying hard not to rant about the review mentality on this list, but I'm
>> afraid I can't totally bite my tongue ... :)
> 
> I am afraid this is less about mentality than the lack of man power.
> This is not a new problem. We have much more code producers than
> reviewers.

It's part of the "take-and-not-give-back review mentality" and I hope
you "smelled" that the comment was not targeted at you.

[...]

>> Although it will make upstreaming stuff *even harder* and *even slower*,
>> maybe we should start to only queue patches that have an ACK/RB, so they
>> won't get blocked by this later on? At least that makes your life easier
>> and people won't have to eventually follow up on patches that have been
>> in linux-next for months.
> 
> I wouldn't mind if patched got merged to mmotm less pro-actively at all.
> People tend to care less to follow up on patches that are in the queue
> already from my past experience. And also it encourages to generate more
> code than review.

The current process will at least encourage me in the long term to
generate less code (changes) as well. I consider patches that have not
been merged upstream as on my TODO list - and it seems to keep on
growing. (yes, there are people that fire-and-forget)

Then, I much rather prefer to just get no reply on my patches, ping two
times, and eventually dump them into the trash. As explained, will WHP
result in me generating less code changes overall. Problem partially
solved (at least one producer less) :)

> 
> This is certainly not a black or white of course. Some areas have barely
> anybody for a review except for the person actively writing code in that
> area so this really needs the case by case approach.

Yes.

> 
> Anyway this is not a new discussion or a new problem we are facing. I
> believe that part of the problem is that the MM subsystem doesn't really
> have official maintainers so there is nobody really responsible for
> particular parts of the subsystem. Sure Andrew is merging patches based
> on the review feedback or his gut feeling but I am afraid this is not
> enough.

If we would have "official maintainers" would it really help (besides
Andrew having less stuff to do of course)? E.g., if you would pick up
the memory hotplug patches, you would still have to have a look at them
- it's still the producer-consumer imbalance (and you would have an even
higher workload).

But yeah, we should most probably finally have official maintainers. For
people sending patches, it's often not obvious whom to cc (and whom to
ping).

Smells like a "LSF/MM/BPF TOPIC", but as you said, it's not a new
problem/discussion. (I won't be around, so I can't bring that topic up)


Anyhow, my two cents.

-- 
Thanks,

David / dhildenb



  reply	other threads:[~2020-01-31 10:37 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-06  8:56 [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages() David Hildenbrand
2019-10-06 19:58   ` Damian Tometzki
2019-10-06 20:13     ` David Hildenbrand
2019-10-14  9:05   ` David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 02/10] mm/memmap_init: Update variable name in memmap_init_zone David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 03/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_pgdat_span() David Hildenbrand
2019-10-14  9:31   ` David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span() David Hildenbrand
2019-10-14  9:32   ` David Hildenbrand
2019-10-14 19:17     ` Andrew Morton
2019-11-19 14:16       ` David Hildenbrand
2019-11-19 20:44         ` Andrew Morton
2019-10-06  8:56 ` [PATCH v6 05/10] mm/memory_hotplug: Shrink zones when offlining memory David Hildenbrand
2019-10-14  9:39   ` David Hildenbrand
2019-10-14 19:16     ` Andrew Morton
2019-10-27 22:45   ` David Hildenbrand
2019-11-30 23:21     ` Andrew Morton
2019-11-30 23:43       ` David Hildenbrand
2019-12-18 17:08       ` David Hildenbrand
2019-12-18 20:16         ` Andrew Morton
2019-12-03 15:10   ` Oscar Salvador
2019-12-03 15:27     ` David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 06/10] mm/memory_hotplug: Poison memmap in remove_pfn_range_from_zone() David Hildenbrand
2019-10-16 14:01   ` David Hildenbrand
2020-02-04  8:59   ` Oscar Salvador
2019-10-06  8:56 ` [PATCH v6 07/10] mm/memory_hotplug: We always have a zone in find_(smallest|biggest)_section_pfn David Hildenbrand
2020-02-04  9:06   ` Oscar Salvador
2020-02-05  8:57   ` Wei Yang
2020-02-05  8:59     ` David Hildenbrand
2020-02-05  9:26       ` Wei Yang
2019-10-06  8:56 ` [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span() David Hildenbrand
2020-02-04  9:13   ` Oscar Salvador
2020-02-04  9:20     ` David Hildenbrand
2020-02-04 14:25   ` Baoquan He
2020-02-04 14:42     ` David Hildenbrand
2020-02-05 12:43       ` Baoquan He
2020-02-05 13:20         ` David Hildenbrand
2020-02-05 13:34           ` Baoquan He
2020-02-05 13:38             ` David Hildenbrand
2020-02-05 14:12               ` Baoquan He
2020-02-05 14:16                 ` David Hildenbrand
2020-02-05 14:26                   ` Baoquan He
2020-02-05  9:59   ` Wei Yang
2020-02-05 14:48     ` Baoquan He
2020-02-05 22:56       ` Wei Yang
2020-02-05 23:08         ` Baoquan He
2020-02-05 23:26           ` Wei Yang
2020-02-05 23:30             ` Baoquan He
2020-02-05 23:34               ` Wei Yang
2020-02-05 14:54     ` David Laight
2020-02-05 14:55       ` David Hildenbrand
2019-10-06  8:56 ` [PATCH v6 09/10] mm/memory_hotplug: Drop local variables " David Hildenbrand
2020-02-04  9:26   ` Oscar Salvador
2020-02-04  9:29     ` David Hildenbrand
2020-02-05 10:07   ` Wei Yang
2019-10-06  8:56 ` [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages() David Hildenbrand
2020-02-04  9:46   ` Oscar Salvador
2020-02-04 12:41     ` David Hildenbrand
2020-02-04 13:13       ` Segher Boessenkool
2020-02-04 13:38         ` David Hildenbrand
2020-02-05 12:51           ` Segher Boessenkool
2020-02-05 13:17             ` David Hildenbrand
2020-02-05 13:18               ` David Hildenbrand
2020-02-05 13:23                 ` David Hildenbrand
2020-02-05 11:48   ` Wei Yang
2019-12-02  9:09 ` [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-12-03 13:36   ` Oscar Salvador
2020-01-31  4:40     ` Andrew Morton
2020-01-31  9:18       ` David Hildenbrand
2020-01-31 10:03         ` Michal Hocko
2020-01-31 10:36           ` David Hildenbrand [this message]
2020-02-04  1:46         ` Andrew Morton
2020-02-04  8:45           ` David Hildenbrand
2020-02-04  9:51             ` 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=c1758220-14c8-2f0f-7fd3-68da0fc9bf94@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=cai@lca.pw \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=dalias@libc.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=glider@google.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ira.weiny@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=logang@deltatee.com \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=osalvador@suse.de \
    --cc=pagupta@redhat.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pasic@linux.ibm.com \
    --cc=paulus@samba.org \
    --cc=pavel.tatashin@microsoft.com \
    --cc=peterz@infradead.org \
    --cc=richard.weiyang@gmail.com \
    --cc=richardw.yang@linux.intel.com \
    --cc=robin.murphy@arm.com \
    --cc=rppt@linux.ibm.com \
    --cc=steve.capper@arm.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yaojun8558363@gmail.com \
    --cc=ysato@users.sourceforge.jp \
    --cc=yuzhao@google.com \
    /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).