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 83B93303CB6 for ; Mon, 12 Jan 2026 05:06:23 +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=1768194383; cv=none; b=uaPQSInrjfD84m5+PHoi2aasM12OC57GcqqhZWtmL6Kp4/9Z813uOWU00fnm/bsdNmz99efAsFglHaU30cCv3mZCFGLdkfjtkxQKZaUUGkTch1Nf6Olj80TXV1TmR9rmT7qlyMmkPnuZEX5nFnWVAliGs52BkNVd2ev6Q3p2Dvo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768194383; c=relaxed/simple; bh=x5XK1IS1CHmffJdkNKPIhh1CcWDogeIrFyvBIZ7XcuI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HCw4g6iIsXeFcojc/EXcLSHbofAwnAaPNVqnaqfKoNB1M04GoSclKBqznSSi68YawM1DSaJ3IfLUJJVNc3b/KdhIK8eNpVzJiLhpaLfpwWYy5SwOE/12vwGev3iRgNhlbqAFlkd6WbZC4+aAO6+woAtiWlMxf7riU0K+9r+YhY4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l+MxTUKp; 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="l+MxTUKp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CAF3C116D0; Mon, 12 Jan 2026 05:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768194383; bh=x5XK1IS1CHmffJdkNKPIhh1CcWDogeIrFyvBIZ7XcuI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=l+MxTUKpoBoBH7rXpuW9b5MY3BHMKeVmui5kyqJ9MsdqyTyjTz5d8PfF0nxW5upvT s0nSMKirXG3CHOGDGO0SS2T0o0lS3ZIPQlt3ol1LuwWOwsalzelIVgIcKceVb60Flk +0bx3TrbY/rYAQV0ddNhI4Sy2kAICTPcvJzEb/tTrO6EGTriKTbIR9eP4f6+7cF5t4 KDKirFiiWkBQ13L0p3u58HC/jbMJ7TpGQmOToDMAVeGkX1dfIWb5NXaDOIYLZuWFqi mZQbzUZKTYQm7tort12uf2yEy/dFfcbHuGsetzvzbhzq3fulUWU0bqAY4/JtwZg5Y/ pE7RfpqVqGpVA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id DD692CE0CB8; Sun, 11 Jan 2026 21:06:22 -0800 (PST) Date: Sun, 11 Jan 2026 21:06:22 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Theodore Tso , "Dr. David Alan Gilbert" , Julia Lawall , Sasha Levin , Gabriele Paoloni , Kate Stewart , Chuck Wolber , Dmitry Vyukov , Mark Rutland , Thomas Gleixner , Lorenzo Stoakes , Shuah Khan , Chris Mason , linux-kernel@vger.kernel.org Subject: Re: Follow-up on Linux-kernel code accessibility Message-ID: Reply-To: paulmck@kernel.org References: <7f10c583-4d95-432e-a536-898c79b1766d@paulmck-laptop> <20251229153517.0001e755@gandalf.local.home> <81eda579-1909-4a10-ad81-6f5551bc7db6@paulmck-laptop> <20260109095858.3401c4d9@gandalf.local.home> <20260111033040.GA52543@macsyma.local> <20260111121151.39801d8d@fedora> 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: <20260111121151.39801d8d@fedora> On Sun, Jan 11, 2026 at 12:11:51PM -0500, Steven Rostedt wrote: > On Sat, 10 Jan 2026 19:30:40 -0800 > "Theodore Tso" wrote: > > > > Steven, you may disagree with this conclusion, but speaking > > personally, everything that I've read on this thread strongly confirms > > it. > > I'm not talking about someone with no knowledge about the kernel. If > someone has a strong understanding of how an operating system works, > and a general idea of the system, looking at the comments in the code > should be enough for them to figure out the understanding of what is > happening. > > I look at it as two levels. There's an architectural understanding > (which is achieved via books and design documents and such) and then > there's the implementation details. The implementation details should > be expressed in comments, and actually avoided when possible from the > design and architectural documentation. That's because the > implementation can change, and does often. You seem to be assuming that the implementation can always be understood independent of the architecture. This would be a brave assumption that has not been borne out by my experience. Or am I missing your point? > > I am not sure that we can count on LLM's to provide reliable "active > > software assistance", although a recent experiment, where I enabled > > Gemini 3's "deep research" mode, and asked it the question, "How much > > money do most software engineers need to retire?", resulted in a 15 > > page report[2], with footnotes, so you could verify whether or not the > > LLM was halucinating or not --- and it was much better than I > > expected. I'm not sure I agree with all of it, but it's better than > > many of the YouTube financial advice videos out there. :-) > > > > [2] https://docs.google.com/document/d/1EDqC-qnHkEyEeewXFx4PuL4VtnC_LxPZ2CKlleB7QBc/edit?tab=t.0 > > I fail to understand the analogy of using AI for financial security for > retired software engineers and understanding an implementation of code > by experience developers. > > If I hit a bug that leads me to RCU code, I would hope there's enough > commenting for me to understand if the bug is with RCU or my usage of > RCU. In this case, trawling through the RCU implementation itself would not normally be the first choice. I instead suggest starting with the documentation of RCU's usage. Documentation/RCU has a lot of this, and there is also the 2024 edition of the RCU API: https://lwn.net/Articles/988638. There are of course always exceptions, but this is after all the purpose of RCU's usage documentation. > > Thta being said, there's a big difference between retirement planning > > and trusting a LLM to be able to explain the finer points of say, an > > I/O scheduler, the MM's OOM Killer hueristics, or RCU. I suspect > > there are no silver bullets here. > > There was a performance issue that Joel pointed out which lead to this > one function I was looking at. But with the use of various constants > that don't appear to be documented anywhere made it impossible for me > to know if that code really was the performance issue or not. Sure I > could simply ask Paul or Joel why is 3 so important here, but the fact > I need to ask is a fail in my mind. Failure or not, in this particular case, again, please reach out to Joel while CCing rcu@vger.kernel.org. And again, the current state of RCU commenting is somewhere between "notes to Paul" and sufficient for those working closely with it. And again, I do not expect RCU's commenting to support context free dives into random places in its code any time soon. > I have the same issue with the scheduler. There's parts of the > scheduler that I worked on years ago, but the changes to it, I have no > idea why it's doing what it is doing because there's no comments about > it. The design is basically the same, but the implementation has > changed. I'm going to be actively fixing that, as one of my OKRs is to > comment the scheduler in more detail as to explain why functions do > what they do. A few weeks back, I took the liberty of doing a quick scan through the kernel for use of constants, and there are a *lot* of them. The scheduler and RCU are among the least of the problems. And at least some of the scheduler's use of constants look to be in code implementing digital filters of one sort or another. Such constants tend to be empirical in nature, and the reason for the choice is usually "because this particular value works better than the other choices". But I do applaud your going through the scheduler to improve comments. Going through RCU with Boqun, Frederic, Joel, Neeraj, and Uladzislau certainly greatly improved RCU's comments, inadequate though you apparently consider them to be. And so, as I mentioned earlier, I would be happy to participate in another walkthrough. ;-) Thanx, Paul