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

[Andrew Morton]

On Fri, 31 Jan 2020 10:18:34 +0100 David Hildenbrand <david at redhat.com> 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 ... :)
> 
> 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).

Yes, we've been doing this for a couple of years now.  I make an
exception for Vitaly's zswap patches because he appears to be the only
person who knows the code (since Harry's internship ended).

I think this is the first time we've hit a significant logjam. 
Presumably the holiday season contributed to this.

It isn't clear to me that we've gained much from this policy.  But
until this cycle I've seen little harm.

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

The merge rate would still be the review rate, but the resulting merges
would be of less tested code.

> Note: the result will be that many of my patches will still not get
> reviewed, won't get queued/upstreamed, I will continuously ping and
> resend, I will lose interest because I have better things to do, I will
> lose interest in our code quality, I will lose interest to review.
> 
> (side note: some people might actually enjoy me sending less cleanup
> patches, so this approach might be desirable for some ;) )
> 
> One alternative is to send patches upstream once they have been lying
> around in linux-next for $RANDOM number of months, because they
> obviously saw some testing and nobody started to yell at them once
> stumbling over them on linux-mm.

Yes, I think that's the case with these patches and I've sent them to
Linus.  Hopefully Michel will be able to find time to look them over in
the next month or so.