Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
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:03:41 +0100
Message-ID: <20200131100341.GB24244@dhcp22.suse.cz> (raw)
In-Reply-To: <f7ed4448-8f41-599d-4689-914eeaf84d6d@redhat.com>

On Fri 31-01-20 10:18:34, David Hildenbrand wrote:
> On 31.01.20 05:40, Andrew Morton wrote:
> > On Tue, 3 Dec 2019 14:36:38 +0100 Oscar Salvador <osalvador@suse.de> wrote:
> > 
> >> On Mon, Dec 02, 2019 at 10:09:51AM +0100, David Hildenbrand wrote:
> >>> @Michal, @Oscar, can some of you at least have a patch #5 now so we can
> >>> proceed with that? (the other patches can stay in -next some time longer)
> >>
> >> Hi, 
> >>
> >> I will be having a look at patch#5 shortly.
> >>
> >> Thanks for the reminder
> > 
> > Things haven't improved a lot :(
> > 
> > mm-memmap_init-update-variable-name-in-memmap_init_zone.patch
> > mm-memory_hotplug-poison-memmap-in-remove_pfn_range_from_zone.patch
> > mm-memory_hotplug-we-always-have-a-zone-in-find_smallestbiggest_section_pfn.patch
> > mm-memory_hotplug-dont-check-for-all-holes-in-shrink_zone_span.patch
> > mm-memory_hotplug-drop-local-variables-in-shrink_zone_span.patch
> > mm-memory_hotplug-cleanup-__remove_pages.patch
> > 
> > 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.

In this particular case the review is expected from me and I am
sorry that my bandwith doesn't scale with the email traffic in my inbox.
I do very much appreciate the amount of work you are doing in the
hotplug area but we need more reviewers here.

> Now, this is an uncomfortable situation for you and me. You have to ping
> people about review and patches are stuck in your tree. I have a growing
> list of patches that are somewhat considered "done", but well,
> not-upstream-at-all. I have patches that are long in RHEL and were
> properly tested, but could get dropped any time because -ENOREVIEW.
> 
> Our process nowadays seems to be, to only upstream what has an ACK/RB
> (fixes/features/cleanups). I can understand this is desirable (yet, I am
> not sure if this makes sense with the current take-and-not-give-back
> review mentality on this list).
> 
> 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.

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.

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.
-- 
Michal Hocko
SUSE Labs


  reply index

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-06  8:56 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 [this message]
2020-01-31 10:36           ` David Hildenbrand
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=20200131100341.GB24244@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --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=david@redhat.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=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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org
	public-inbox-index linux-mm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git