From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CE77C35247 for ; Tue, 4 Feb 2020 01:46:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA2052084E for ; Tue, 4 Feb 2020 01:46:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="IWzFutDt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA2052084E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5D0736B0006; Mon, 3 Feb 2020 20:46:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 580696B02DB; Mon, 3 Feb 2020 20:46:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 448216B02DD; Mon, 3 Feb 2020 20:46:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id 2D6EC6B0006 for ; Mon, 3 Feb 2020 20:46:57 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B234F8248047 for ; Tue, 4 Feb 2020 01:46:56 +0000 (UTC) X-FDA: 76450756032.21.humor97_76c23dfc1de11 X-HE-Tag: humor97_76c23dfc1de11 X-Filterd-Recvd-Size: 7450 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 01:46:55 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6D90E20732; Tue, 4 Feb 2020 01:46:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580780815; bh=L7qyiSaKYCSiXFTQrei6zHPTHLJYHqYmnQdeCSNYJUw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IWzFutDti1oCSWF1rKXWbGepy5r6blJTGBSX9wsjZ0oqHgkfm4NxusQXKFZZqkXS4 NPCAIbBhdT0BVAZ8ppji0sqcwu4XIHKjpjrvicl1df/vB4ckh6YRbrrE3EDakSdqrT RtE2FA9knl1TQs3a2jK8E9n8CkAtByewbWYTl5bY= Date: Mon, 3 Feb 2020 17:46:53 -0800 From: Andrew Morton To: David Hildenbrand Cc: Oscar Salvador , linux-kernel@vger.kernel.org, Michal Hocko , 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" , Dan Williams , Alexander Duyck , Alexander Potapenko , Andy Lutomirski , Anshuman Khandual , Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christian Borntraeger , Christophe Leroy , Dave Hansen , Fenghua Yu , Gerald Schaefer , Greg Kroah-Hartman , Halil Pasic , Heiko Carstens , "H. Peter Anvin" , Ingo Molnar , Ira Weiny , Jason Gunthorpe , Jun Yao , Logan Gunthorpe , Mark Rutland , Masahiro Yamada , "Matthew Wilcox (Oracle)" , Mel Gorman , Michael Ellerman , Mike Rapoport , Pankaj Gupta , Paul Mackerras , Pavel Tatashin , Pavel Tatashin , Peter Zijlstra , Qian Cai , Rich Felker , Robin Murphy , Steve Capper , Thomas Gleixner , Tom Lendacky , Tony Luck , Vasily Gorbik , Vlastimil Babka , Wei Yang , Wei Yang , Will Deacon , Yoshinori Sato , Yu Zhao Subject: Re: [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory Message-Id: <20200203174653.74630ef5744c68be55374b0d@linux-foundation.org> In-Reply-To: References: <20191006085646.5768-1-david@redhat.com> <20191203133633.GA2600@linux> <20200130204043.29e21049775e3a637db733e0@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 31 Jan 2020 10:18:34 +0100 David Hildenbrand wrote: > On 31.01.20 05:40, Andrew Morton wrote: > > On Tue, 3 Dec 2019 14:36:38 +0100 Oscar Salvador 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.