[PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory

[Michal Hocko]

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 at 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