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

[David Hildenbrand]

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

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.

-- 
Thanks,

David / dhildenb