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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4194D75BD9 for ; Thu, 21 Nov 2024 09:03:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFB876B0082; Thu, 21 Nov 2024 04:03:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DAB9C6B0083; Thu, 21 Nov 2024 04:03:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9A796B0088; Thu, 21 Nov 2024 04:03:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ABBAD6B0082 for ; Thu, 21 Nov 2024 04:03:58 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5AEA1C0ABF for ; Thu, 21 Nov 2024 09:03:58 +0000 (UTC) X-FDA: 82809511260.17.FE356F7 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) by imf26.hostedemail.com (Postfix) with ESMTP id 7533314001A for ; Thu, 21 Nov 2024 09:03:16 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HiOO3Ibu; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732179775; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FRLw+DGKdwBq59yleVzq1+0cEo5aRODfgmqZBbkpOO8=; b=HgHlwquxEAzevt9yAnE/YN5MeXMrLnlw50Q5oOPc/CQnV1jmK+cGrEq3dBXhSWM9Heax9V phSt+OmbnC7b6L3vrHZoAtP6A5dbU+QGmFqoKtK7ekOg5u8/KF+Ve+Mg9mG1hCpqJkMYOq zUvORCWdIBTG3YSzvWn+W7EoN7zkgUI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732179775; a=rsa-sha256; cv=none; b=kZdyYjF7Dq4Je62aV4zO1dcW8kya8QBRe2XDHl0koZO4wC/9tTZY1RvnojYlOwyjuF20u4 rShKzoHjpv9p53OW9aPWnU49NssYkZOds23hohdvY3GAEsnWEvx6bgNFJR/BhoGrV2EIAg I7mWajVignksRsrSrKj7OK/XJQocRFc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HiOO3Ibu; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 21 Nov 2024 04:03:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1732179833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FRLw+DGKdwBq59yleVzq1+0cEo5aRODfgmqZBbkpOO8=; b=HiOO3Ibumb6pS42WpgNsTAOgm0t1JNKUQXlVy4TDWQpC6qMR5Mu2auqGAp/9UcRs4mpQqg BTWLfzZkEJLvYUAnXH3M3QzIZgaLoNBtZfZU53hBdNRFeHRYX2v0Ve7bDDqF0uCtR1qI3I NG98hydgjDXFeWfNtktWDltia42/XJ0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Shuah Khan , Dave Chinner , Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, "conduct@kernel.org" Subject: Re: review process (was: underalated stuff) Message-ID: References: <22a3da3d-6bca-48c6-a36f-382feb999374@linuxfoundation.org> <71b51954-15ba-4e73-baea-584463d43a5c@linuxfoundation.org> <9efc2edf-c6d6-494d-b1bf-64883298150a@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: hcaq4mqpaqsz4cywz6eyb9zt6jh3jzkr X-Rspam-User: X-Rspamd-Queue-Id: 7533314001A X-Rspamd-Server: rspam02 X-HE-Tag: 1732179796-231094 X-HE-Meta: U2FsdGVkX1/gFCDrMEaRPYXzHOWthbSOckP/qChL/AOIojWvl5KiGG/Xw3+74fyE36PAwQnQ+5I+dbwMenj1WJY3qsZMRLX+hP+taaBHSHgqBxBvRzSClwdoj4friBE2KHs36EnxNTKzJmEKp+XKwDaA2aDFfZraVQBjJeGI5zhDyArG4xreoKW74MJrrvnI3uzHVTkAmnHZTfReBcWA0422eFwyc6p6o4oC7bFaEo16hxmnMialAyNn0VwEq2EnaO9sclvT2Br73zCBsWGMqOY53d5poVqbt9stKyD6AXZT9WghSVRzujUFWcJRWZmlntT+Itlcdc/bnQyZG157r8ZmZJNcgkAmsrcfwBuBXnZxScirc+ngsUWPARUT3RAGDBWZ2J7aaC78RG0ZFzC0TgGiiW9FJK/m6MFOb8JazV1razmYpP9An63kFwhoidlkhirMcCO1J8+3NJaUIMNIpEK8A+j60ixyVdidCrggDFVv4RXeP9Amv/tXHXU/YlpgmkqFhu6O8QBUykFJwzuRxz/9APjtkvReQZk3QEEgTtgT3o5WLw+QCTT+tnRliK0WJVp1TWpt5yeI4bvRGUxeLEYAFg0Ja+qXGhfAmdK4YwPikhSX5CDs8FKwFErs/PN4TqXlMiYhjxopbtMWrvW2xpCSphYfXzWnJNh6xXA1r1n4aZwc+1oDHdKwjKHnU5d+TKM1hOL+nwJtJq1RCw4JXCcAW5wN4VLvZA04GfE1xTkLoGlRLxVbll+KV/waAuUwVi3giA6Fxmuae9G6WQHiQhjKgeZKmQSZZEXJzt29d0JTnxZhEqrIUQXSq7H3HEbiS1BwbVNrL84RgKcrJLSNDUAQAAwA9iIQuyp1u6F2I3KkbUarDUlEBP1vVaRfRbU2clP/p3vjfecIqHEJLez147tAMZDpnIh1eSgoXhIjNwmk7DbkyjIZh2rQyMxtWqXnQGL/s7s2D9dJNO5MBOI Nfl9Mr8V n0kEwFXD22w7QJBhxlWh9v4T0UAEwarm/gYX34BTnaZC94rahPRgmMnHrFppINsU+uxk87ehkRQsWZ96FVshwRUKZeN4/R4Ujub2/vov0CWX+JhT0ZGUVW98RFxisUFO5NS+tTLY4cvAuaiFBtzxgkG6yS7kCtEernEvhzzLkvo6rROQCkwZGuL94Lu7oOEE3pzT/d2Jr9+BEdMensQ16J/oX5Ld2WMRH0TGeTWyuUGDA2akWpV+iLgYjUwOyvx14y4Vw08TOW/NYJCOTMZhYLnEJqPDXE/CLxLx7BMwxaAQScnVR6uJzmWhujaxoEbLAwBTdCvUAdZYU0w3fFMZc2WmHWA== 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 21, 2024 at 09:43:21AM +0100, Michal Hocko wrote: > On Wed 20-11-24 17:39:09, Kent Overstreet wrote: > > Michal's (as well as Steve's) behaviour in the memory allocation > > profiling review process was, in my view, unacceptable (this included > > such things as crashing our LSF presentation with ideas they'd come up > > with that morning, and persistent dismissive axegrinding on the list). > > The project was nearly killed because of his inability to listen to the > > reasons for a design and being stubbornly stuck on his right to be heard > > as the maintainer. > > Couple of entry points that might be helful for that. > https://lore.kernel.org/all/YxBc1xuGbB36f8zC@dhcp22.suse.cz/ > I have expressed my concerns and set expectations to move the > work forward. I've had couple of back and forth with Suren about > specifics of overhead assumptions from the stack unwinding IIRC. > > For the first non-RFC version my feedback was > https://lore.kernel.org/all/ZFIMaflxeHS3uR%2FA@dhcp22.suse.cz/#t > not really "maintenance burden only" but a request to show that alternative > approaches have been explored. It was not particularly helpful that you > had expected tracing people would implement the feature for you. > https://lore.kernel.org/all/20230503092128.1a120845@gandalf.local.home/ > Other people have also expressed that this is not completely impossible > https://lore.kernel.org/all/ZFKNZZwC8EUbOLMv@slm.duckdns.org/ > The rest of the email thread is mostly a combat zone that I have avoided > participating as much as possible. > > I didn't have any reaction to v2 at all. > > v3 was aiming to be merged and I've stepped up as there was no single > review at the time https://lore.kernel.org/all/Zctfa2DvmlTYSfe8@tiehlicka/ > > I admit that I was really open that I do not like the solution and I've > said reasons for that. Allocator APIs have always been a large mess of > macros, static inlines that makes it really far from free to maintain > and alternative ways should be considered before going that route. > > I was also clear that support by MM people was necessary to get this > merged. I have explicitly _not_ NAKed the series and backed off for you > guys to gain that support. > > So essentially there was a clear outline for you and Sure how to achieve > that. > > I would really like to hear from other maintainers. Is tnis really > unacceptable maintainer behavior? I am OK to apologize but the above is > in line of my understanding of how to ack properly. I wonder if I was reading too much into what you were saying in the off-list thread, when I said "argument to authority". Can you tell me if this might be closer to the mark? If I read you correctly, when you said you were "voicing your concerns", I took it as you being pushy because that was the effects: I need you to take me at my word, because you didn't see everything behind the scenes, that this did derail and nearly kill the project. But I should've been taking you at your word, that you just really were that concerned. I think the best way I can explain this issue is with an analogy to parenting: when we're parenting, our first and foremost job isn't really to make sure there's a roof, shelter, food - that part is easy in today's world. The main job really is to make sure that people feel safe, that they can go out and explore the world without being terrified. In order to do that, we have to master our own fears, we can't be projecting them all the time. Being a maintainer, or any kind of leader, is the exact same thing. My big lesson on this was watching Andrew, back during the process of merging MGLRU - I couldn't believe at the time how chill he was about it. But he understood the process, and he's a master at this. Part of mastering our fears in a group setting like this is learning to trust other people. It's not that your concerns didn't have any validity - but we were already doing as much as we could to address them, and you didn't show any trust that we, I especially, knew what we were doing. And that led to a _lot_ of wasted effort down blind alleys that I already knew weren't going to work. I think that may be what this is really about, sometimes you do have to trust that people know what they're doing; you share your knowledge if you have knowledge to share, otherwise you have to back off and let people do their work. Otherwise the whole thing breaks down and no one can get anything done. The main thing is I just want to ask yourself if you could have done anything better in the memory allocation profiling process. I don't need you to apologize for anything specific, if you can just try to work better together in the future that's all I need.