From: David Hildenbrand <david@redhat.com> To: Michal Hocko <mhocko@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Oscar Salvador <osalvador@suse.de>, 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" <aneesh.kumar@linux.ibm.com>, Dan Williams <dan.j.williams@intel.com>, Alexander Duyck <alexander.h.duyck@linux.intel.com>, Alexander Potapenko <glider@google.com>, Andy Lutomirski <luto@kernel.org>, Anshuman Khandual <anshuman.khandual@arm.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Borislav Petkov <bp@alien8.de>, Catalin Marinas <catalin.marinas@arm.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Christophe Leroy <christophe.leroy@c-s.fr>, Dave Hansen <dave.hansen@linux.intel.com>, Fenghua Yu <fenghua.yu@intel.com>, Gerald Schaefer <gerald.schaefer@de.ibm.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Halil Pasic <pasic@linux.ibm.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Ira Weiny <ira.weiny@intel.com>, Jason Gunthorpe <jgg@ziepe.ca>, Jun Yao <yaojun8558363@gmail.com>, Logan Gunthorpe <logang@deltatee.com>, Mark Rutland <mark.rutland@arm.com>, Masahiro Yamada <yamada.masahiro@socionext.com>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, Mel Gorman <mgorman@techsingularity.net>, Michael Ellerman <mpe@ellerman.id.au>, Mike Rapoport <rppt@linux.ibm.com>, Pankaj Gupta <pagupta@redhat.com>, Paul Mackerras <paulus@samba.org>, Pavel Tatashin <pasha.tatashin@soleen.com>, Pavel Tatashin <pavel.tatashin@microsoft.com>, Peter Zijlstra <peterz@infradead.org>, Qian Cai <cai@lca.pw>, Rich Felker <dalias@libc.org>, Robin Murphy <robin.murphy@arm.com>, Steve Capper <steve.capper@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Tom Lendacky <thomas.lendacky@amd.com>, Tony Luck <tony.luck@intel.com>, Vasily Gorbik <gor@linux.ibm.com>, Vlastimil Babka <vbabka@suse.cz>, Wei Yang <richard.weiyang@gmail.com>, Wei Yang <richardw.yang@linux.intel.com>, Will Deacon <will@kernel.org>, Yoshinori Sato <ysato@users.sourceforge.jp>, Yu Zhao <yuzhao@google.com> Subject: Re: [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory Date: Fri, 31 Jan 2020 11:36:52 +0100 Message-ID: <c1758220-14c8-2f0f-7fd3-68da0fc9bf94@redhat.com> (raw) In-Reply-To: <20200131100341.GB24244@dhcp22.suse.cz> >>> 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. It's part of the "take-and-not-give-back review mentality" and I hope you "smelled" that the comment was not targeted at you. [...] >> 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. The current process will at least encourage me in the long term to generate less code (changes) as well. I consider patches that have not been merged upstream as on my TODO list - and it seems to keep on growing. (yes, there are people that fire-and-forget) Then, I much rather prefer to just get no reply on my patches, ping two times, and eventually dump them into the trash. As explained, will WHP result in me generating less code changes overall. Problem partially solved (at least one producer less) :) > > 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. Yes. > > 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. If we would have "official maintainers" would it really help (besides Andrew having less stuff to do of course)? E.g., if you would pick up the memory hotplug patches, you would still have to have a look at them - it's still the producer-consumer imbalance (and you would have an even higher workload). But yeah, we should most probably finally have official maintainers. For people sending patches, it's often not obvious whom to cc (and whom to ping). Smells like a "LSF/MM/BPF TOPIC", but as you said, it's not a new problem/discussion. (I won't be around, so I can't bring that topic up) Anyhow, my two cents. -- Thanks, David / dhildenb
next prev parent reply index Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-06 8:56 David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages() David Hildenbrand 2019-10-06 19:58 ` Damian Tometzki 2019-10-06 20:13 ` David Hildenbrand 2019-10-14 9:05 ` David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 02/10] mm/memmap_init: Update variable name in memmap_init_zone David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 03/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_pgdat_span() David Hildenbrand 2019-10-14 9:31 ` David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span() David Hildenbrand 2019-10-14 9:32 ` David Hildenbrand 2019-10-14 19:17 ` Andrew Morton 2019-11-19 14:16 ` David Hildenbrand 2019-11-19 20:44 ` Andrew Morton 2019-10-06 8:56 ` [PATCH v6 05/10] mm/memory_hotplug: Shrink zones when offlining memory David Hildenbrand 2019-10-14 9:39 ` David Hildenbrand 2019-10-14 19:16 ` Andrew Morton 2019-10-27 22:45 ` David Hildenbrand 2019-11-30 23:21 ` Andrew Morton 2019-11-30 23:43 ` David Hildenbrand 2019-12-18 17:08 ` David Hildenbrand 2019-12-18 20:16 ` Andrew Morton 2019-12-03 15:10 ` Oscar Salvador 2019-12-03 15:27 ` David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 06/10] mm/memory_hotplug: Poison memmap in remove_pfn_range_from_zone() David Hildenbrand 2019-10-16 14:01 ` David Hildenbrand 2020-02-04 8:59 ` Oscar Salvador 2019-10-06 8:56 ` [PATCH v6 07/10] mm/memory_hotplug: We always have a zone in find_(smallest|biggest)_section_pfn David Hildenbrand 2020-02-04 9:06 ` Oscar Salvador 2020-02-05 8:57 ` Wei Yang 2020-02-05 8:59 ` David Hildenbrand 2020-02-05 9:26 ` Wei Yang 2019-10-06 8:56 ` [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span() David Hildenbrand 2020-02-04 9:13 ` Oscar Salvador 2020-02-04 9:20 ` David Hildenbrand 2020-02-04 14:25 ` Baoquan He 2020-02-04 14:42 ` David Hildenbrand 2020-02-05 12:43 ` Baoquan He 2020-02-05 13:20 ` David Hildenbrand 2020-02-05 13:34 ` Baoquan He 2020-02-05 13:38 ` David Hildenbrand 2020-02-05 14:12 ` Baoquan He 2020-02-05 14:16 ` David Hildenbrand 2020-02-05 14:26 ` Baoquan He 2020-02-05 9:59 ` Wei Yang 2020-02-05 14:48 ` Baoquan He 2020-02-05 22:56 ` Wei Yang 2020-02-05 23:08 ` Baoquan He 2020-02-05 23:26 ` Wei Yang 2020-02-05 23:30 ` Baoquan He 2020-02-05 23:34 ` Wei Yang 2020-02-05 14:54 ` David Laight 2020-02-05 14:55 ` David Hildenbrand 2019-10-06 8:56 ` [PATCH v6 09/10] mm/memory_hotplug: Drop local variables " David Hildenbrand 2020-02-04 9:26 ` Oscar Salvador 2020-02-04 9:29 ` David Hildenbrand 2020-02-05 10:07 ` Wei Yang 2019-10-06 8:56 ` [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages() David Hildenbrand 2020-02-04 9:46 ` Oscar Salvador 2020-02-04 12:41 ` David Hildenbrand 2020-02-04 13:13 ` Segher Boessenkool 2020-02-04 13:38 ` David Hildenbrand 2020-02-05 12:51 ` Segher Boessenkool 2020-02-05 13:17 ` David Hildenbrand 2020-02-05 13:18 ` David Hildenbrand 2020-02-05 13:23 ` David Hildenbrand 2020-02-05 11:48 ` Wei Yang 2019-12-02 9:09 ` [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand 2019-12-03 13:36 ` Oscar Salvador 2020-01-31 4:40 ` Andrew Morton 2020-01-31 9:18 ` David Hildenbrand 2020-01-31 10:03 ` Michal Hocko 2020-01-31 10:36 ` David Hildenbrand [this message] 2020-02-04 1:46 ` Andrew Morton 2020-02-04 8:45 ` David Hildenbrand 2020-02-04 9:51 ` Oscar Salvador
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c1758220-14c8-2f0f-7fd3-68da0fc9bf94@redhat.com \ --to=david@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.h.duyck@linux.intel.com \ --cc=aneesh.kumar@linux.ibm.com \ --cc=anshuman.khandual@arm.com \ --cc=benh@kernel.crashing.org \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=christophe.leroy@c-s.fr \ --cc=dalias@libc.org \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=fenghua.yu@intel.com \ --cc=gerald.schaefer@de.ibm.com \ --cc=glider@google.com \ --cc=gor@linux.ibm.com \ --cc=gregkh@linuxfoundation.org \ --cc=heiko.carstens@de.ibm.com \ --cc=hpa@zytor.com \ --cc=ira.weiny@intel.com \ --cc=jgg@ziepe.ca \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=logang@deltatee.com \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@kernel.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=osalvador@suse.de \ --cc=pagupta@redhat.com \ --cc=pasha.tatashin@soleen.com \ --cc=pasic@linux.ibm.com \ --cc=paulus@samba.org \ --cc=pavel.tatashin@microsoft.com \ --cc=peterz@infradead.org \ --cc=richard.weiyang@gmail.com \ --cc=richardw.yang@linux.intel.com \ --cc=robin.murphy@arm.com \ --cc=rppt@linux.ibm.com \ --cc=steve.capper@arm.com \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=tony.luck@intel.com \ --cc=vbabka@suse.cz \ --cc=will@kernel.org \ --cc=willy@infradead.org \ --cc=x86@kernel.org \ --cc=yamada.masahiro@socionext.com \ --cc=yaojun8558363@gmail.com \ --cc=ysato@users.sourceforge.jp \ --cc=yuzhao@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ linux-mm@kvack.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git