From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 490B833688D for ; Tue, 24 Mar 2026 07:58:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774339102; cv=none; b=emo+NKO3SkwKChMUvWfbSmQgEh5ZUo7tGI2ULN7O4wG8TcA5XDgoWYL76BPDDN0MW0mavZma4UEoXNbxdbk3cyGKc63DxAxajvGzZ+89fdthyGgluKFgGgKzJJMjG3I/d3ZspLBpKSXucXXtjqxaD6kaL+c+74FZq0lMGP0hixA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774339102; c=relaxed/simple; bh=hNlIhMrnoaeK7dW/zd8nU5BBV1Mm3cRRYly6T6Yi7ug=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MWS1L8+W9HyHUBPoeXQ3wxK51xV+hkHnseMfTek673/IziH//JU3T70QomwF9LcirKyEGpWvfmp/frobtZ7WxNOidYnku3MKOiJ7OA2Ow7SoI72MVEve+WnzpE+DxlUmpqy9+M5w6WIPrPRE22/tWsbvFkNUUwPVog1KofXDlbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BfYtF0MN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BfYtF0MN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F238C19424; Tue, 24 Mar 2026 07:58:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774339101; bh=hNlIhMrnoaeK7dW/zd8nU5BBV1Mm3cRRYly6T6Yi7ug=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BfYtF0MNVdjXZ5ZsElUjeXglMH7FXgwoQMkpDxwKn2c5N5x+Hy9C6jOoowjeIUlrN bJx0jExABLbSFr4+4+HmklH4/tRgFc/uH8Lh2EJaHZqVe7BmDKGrsrsB7oyp+cDoqB t31YCOL8U1WW3VkKDgjtkwSTPjM8V/G2j9QXVEXM856Jts3hm/JFg7kOYPBwovk1X8 vT+JCTzsLuIBPXg5gBjjSXSdcIkFPO6a4H+5eoVBtDHxUx963SpJYIu9UknYf9ilFB VNvBhS0IUWPpvcUbnUcll3BVN1QtdNIaf2t4IyeXhyIhb1maDtbheV9P8luq+5P/fp RgpC/Cj9FWxdw== Date: Tue, 24 Mar 2026 09:58:12 +0200 From: Mike Rapoport To: Andrew Morton Cc: Pedro Falcato , "Lorenzo Stoakes (Oracle)" , Roman Gushchin , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() Message-ID: References: <20260319200917.ce345a369d035050b6329ac5@linux-foundation.org> <87tsu9kgv3.fsf@linux.dev> <20260320203311.715ed75bcd84c18d24894324@linux-foundation.org> <20260321171530.8b3e8207f89d5a7384b9f01f@linux-foundation.org> <5cd57c69-7193-422f-b6b5-75bb5234e5f3@lucifer.local> <20260323143604.603b20aec4e3ab77cabec107@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260323143604.603b20aec4e3ab77cabec107@linux-foundation.org> On Mon, Mar 23, 2026 at 02:36:04PM -0700, Andrew Morton wrote: > On Mon, 23 Mar 2026 12:34:31 +0000 Pedro Falcato wrote: > > > > FWIW I wholeheartedly agree. I don't understand how we don't require proper > > M: or R: reviews on patches before merging > > I wish people would stop making this claim, without substantiation. > I've looked (deeply) at the data, which is equally available to us all. > Has anyone else? > > After weeding out a few special cases (especially DAMON) (this time > also maple_tree), the amount of such unreviewed material which enters > mm-stable and mainline is very very low. Here's a breakout of MM commit tags (with DAMON excluded) since 6.10: ------------------------------------------------------------------------------ Release Total Reviewed-by Acked-by only No review DAMON excl ------------------------------------------------------------------------------ v6.10 318 206 (65%) 36 (11%) 76 (24%) 10 v6.11 270 131 (49%) 72 (27%) 67 (25%) 17 v6.12 333 161 (48%) 65 (20%) 107 (32%) 18 v6.13 180 94 (52%) 29 (16%) 57 (32%) 8 v6.14 217 103 (47%) 40 (18%) 74 (34%) 30 v6.15 289 129 (45%) 45 (16%) 115 (40%) 43 v6.16 198 126 (64%) 44 (22%) 28 (14%) 16 v6.17 245 181 (74%) 41 (17%) 23 (9%) 53 v6.18 205 150 (73%) 28 (14%) 27 (13%) 34 v6.19 228 165 (72%) 33 (14%) 30 (13%) 64 ------------------------------------------------------------------------------ There's indeed sharp reduction in amount of unreviewed material that gets merged since v6.15, i.e. after the last LSF/MM when we updated the process and nominated people as sub-maintainers and reviewers for different parts of MM. This very much confirms that splitting up the MM entry and letting people to step up as sub-maintaners pays off. But we are still at double digits for percentage of commits without Reviewed-by tags despite the effort people (especially David and Lorenzo) are putting into review. I wouldn't say that even 9% is "very very low". > > Like, sure, sashiko can be useful, and is better than nothing. But unless > > sashiko is better than the maintainers, it should be kept as optional. > > Rule #1 is, surely, "don't add bugs". This thing finds bugs. If its > hit rate is 50% then that's plenty high enough to justify people > spending time to go through and check its output. > > > Seriously, I can't wrap my head around the difference in treatment in > > "human maintainers, experts in the code, aren't required to review a patch" > > Speaking of insulting. > > > vs "make the fscking AI happy or it's not going anywhere". It's almost > > insulting. > > Look, I know people are busy. If checking these reports slows us down > and we end up merging less code and less buggy code then that's a good > tradeoff. If you think this is a good trade-off, then slowing down to wait for human review so we merge up less buggy or less maintainable code is a good trade-off too. While LLMs can detect potential bugs, they are not capable to identify potential maintainability issues. > Also, gimme a break. Like everyone else I'm still trying to wrap my > head how best to incorporate this new tool into our development > processes. It would be nice if we had a more formal description of our development process in Documentation/process/maintainer-mm.rst and then we can add a few sentences about how to incorporate this tool into the process when we figure this out. Right now our process is a tribal knowledge, having "Rule #1" and a few others written down would help everyone who participates in MM development. -- Sincerely yours, Mike.