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=-1.0 required=3.0 tests=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 F3112C33CB2 for ; Fri, 31 Jan 2020 10:03:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AFDFF206F0 for ; Fri, 31 Jan 2020 10:03:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFDFF206F0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5B00B6B05B6; Fri, 31 Jan 2020 05:03:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 510E66B05B7; Fri, 31 Jan 2020 05:03:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D9536B05B8; Fri, 31 Jan 2020 05:03:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 25B2D6B05B6 for ; Fri, 31 Jan 2020 05:03:46 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A50D61EF2 for ; Fri, 31 Jan 2020 10:03:45 +0000 (UTC) X-FDA: 76437492810.28.arm94_393b2498390c X-HE-Tag: arm94_393b2498390c X-Filterd-Recvd-Size: 8039 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jan 2020 10:03:44 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id c84so7952084wme.4 for ; Fri, 31 Jan 2020 02:03:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OPsHxJ/qrNw2BAodGghsankc2sSPSX/p9KvFZKbsCyY=; b=Y0UBkeNd8dlfitBVr3m9kBcsKVY99LsnEbkprW28Yg3jJtKqosFdHM1pCiHeWeLgcE dVvWrQOqgz75ID2tuQY42JQt8JkqmuoZxOo/faBKRoQR9gkjByhsm0u6DLIhQeHFAa7Z 7tAFohVAwuapxSbeNz/Mmb/wx4D+KV7R8zIMcUFbUXql3uXccNdHZ3Ug+pnJswtopzqJ ELazghT3P7AxQ3dJnMoPFD1zT66CpQUgZqfuUhuYIEhy6+4rUtJcXmRzWXvD9qHFwlQZ TQYR5gNbph9KatXcdjGuWJEOnCL9mcebyOs72U2It+ZsvBCEMRCMmmbtrrISumNy3AH3 gvQg== X-Gm-Message-State: APjAAAU9s7Xwu1lYsnrhDetO8ftJ3/oFZRDDXnOOHNeUhMm+eklB8Oat 4IgMsE9bW74bznhSvUgNbFg= X-Google-Smtp-Source: APXvYqzLpwtZkdrzGqTPGoiYvY04l7YoTAkF1ULJLn3qG79xKaRmqXLPztVVPxRu9W90SrfOXGU8Zw== X-Received: by 2002:a1c:541b:: with SMTP id i27mr11974379wmb.137.1580465023231; Fri, 31 Jan 2020 02:03:43 -0800 (PST) Received: from localhost (ip-37-188-238-177.eurotel.cz. [37.188.238.177]) by smtp.gmail.com with ESMTPSA id q11sm11424808wrp.24.2020.01.31.02.03.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jan 2020 02:03:42 -0800 (PST) Date: Fri, 31 Jan 2020 11:03:41 +0100 From: Michal Hocko To: David Hildenbrand Cc: Andrew Morton , Oscar Salvador , 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" , 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: <20200131100341.GB24244@dhcp22.suse.cz> References: <20191006085646.5768-1-david@redhat.com> <20191203133633.GA2600@linux> <20200130204043.29e21049775e3a637db733e0@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-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 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