On 6/29/26 11:29, Lorenzo Stoakes wrote: > TL;DR - please don't send unfiltered LLM code to list _at all_. If you want > to share it, link to a repo. > > On Sat, Jun 27, 2026 at 09:36:51AM -0400, Rik van Riel wrote: >> That is the one reason I sent out RFC code before it >> is ready. I am looking for feedback on the concepts >> in this series. > ... >> Once I know what I need to do, coming up with a >> cleaner implementation is very doable. > ... >> The mess in the RFC is the result of trying something >> that seemed right, watching it fail in some subtle >> way, and trying to fix it up. > ... >> > But the execution has to be _completely_ rethought. >> >> There's no argument there. > ... >> > Another issue here is maintainer time - even this _extremely_ light- >> > touch >> > review has taken me a few hours (of my weekend :). To review it in >> > detail >> > would take probably DAYS of dedicated work. >> >> I suspect there is a mismatch in expectations here. >> >> I already knew this code has to be totally redone. > > I'm glad we are in agreement on this :) > > But in general I feel you have sent this and at least one other series like > this > without being as clear as you should have been. > > I hate to belabour the point but just to be clear: > > * You label one patch [DO-NOT-MERGE], but none of the others (implying they > are candidates for being merged) [0] and the cover letter has TODOs, > including trivia like naming, but nothing about the code. > > * You sent a non-RFC series with identical code quality issues [1] > recently. > > * Until I pointed it out, you were responding to other review here as if > the series was genuinely was intended for (eventual) merge: > > - "This is a userspace-visible removal. Writes to > /proc/sys/vm/watermark_boost_factor will now return -ENOENT instead of > being accepted, breaking userspace." [2] > > <-: "I'll just drop this patch for now." [3] > > - "I left a small code nit inline, but whether you take that suggestion > or leave it, you can add Reviewed-by: ..." [4] > > <-: "I sent it with this series mostly because it's needed to make the > series work, and to provide context on why it's needed. I'm happy to > resend it with a GFP mask passed in by each caller. That would look > better, indeed!" [5] > > So to be concrete, if you send really rough code, Use [pre-RFC] or [DO NOT > MERGE] (on the series as a whole) to make that clear and say so in the > cover letter VERY VERY clearly.
Yes please. [POC NOT-FOR-MERGE] perhaps? > Or, you can put it in a repo somewhere and link it in an email discussing > the concepts (like I did with scalable CoW for instance). Indeed. > As above, firstly make it clear that the code you are sending for review is > not to be reviewed so people don't waste highly contended maintainer time > on that! :) > > Also, you didn't respond to my point regarding cc'ing the right people - > but that's clearly something you need to get right if you want this kind of > feedback to start with. > > For instance, you didn't cc- the page allocator maintainer (Vlastimil) on a > series that is fundamentally changing the page allocator. That's not going > to help with feedback. Right! Thanks a lot for adding me, Lorenzo. > In general, this area of the page allocator and compaction isn't my > specialism in the kernel so I can't give you the in-depth feedback you need > on that. > > But I do have thoughts in general as to how to achieve what you want here: > > Firstly - you should try to summarise what you're doing here and what > you're changing alongside the trade-offs as clearly as you can in the cover > letter. > > Then highlight what it is you need feedback on, broken out into clear > questions or points that make it easy for people to respond to. Yep. > And _you have already done this_ in your reply here: > > * "How do people feel about splitting up the free lists, so each gigabyte > (well, PUD sized) chunk of memory has its own free lists?" My immediate response is that now we'd need to search multiple sets of lists instead of a single one? What about the overhead? Having a POC (even vibe-coded) for measuring that overhead might be actually useful to quickly figure out whether the idea is viable or not. But then the code doesn't need to be sent as a huge series if it's not for review. As Lorenzo said, git repo link is enough. > * "How can we balance the desire for higher-order kernel allocations, > against the desire to preserve gigabyte sized chunks of memory that can > be used for user space?" > > * "How do we balance the desire to keep compaction overhead low with the > desire to do higher order allocations almost everywhere?" How can we have a cake and eat it too? :) > I think a really good way of doing this would be to start out with > something like: > > Right now compaction often fails to achieve what we need, with > fragmentation occurring anyway and (for instance) THP stalling on > the availability of higher order folios. > > etc. etc. > > Summarising _the problem_. > > Then a section about your proposed solution, e.g.: > > I propose a means by which we proactively achieve gigabyte-sized > pageblocks with logic which maintains these as physically > contiguous under both ordinary and contended workloads > > Then list out the "secret sauce" of your approach, e.g.: > > This works by arranging memory such that unmovable allocations are > grouped at <blah blah blah> etc. > > Then raise your questions e.g.: > > I'd like to ask the community - how do people feel about splitting > up the free lists, so each gigabyte (well, PUD sized) chunk of > memory has its own free lists? <etc. etc.> > > Then make it clear whether this is an RFC that is ready for primetime or > not: > > This series is simply intended as a proof-of-concept - PLEASE DO > NOT REVIEW THE CODE per-se, but rather comment on the concepts! > > (And obviously as above, if that _is_ what you intend, underline it with > [DO NOT MERGE] or [pre-RFC] or something like that). Ack. > I'd also very strongly suggest (as I did in my original reply) breaking out > parts that can be broken out as prerequisite series. > > If you're doing something good or useful _anyway_ then just send that > separately first, and have later work rely on the earlier work. Ack. > There's no rush, this is huge and will take time. > > A final KEY point: > > NEVER submit unfiltered code generated by an LLMs to the list in _any_ > form. If you want people to access code like that to test or something, > then put it in a remote repo and link to it. > > The code is SO overly complicated and SO messy that it's really difficult > for people to understand what's actually going on. > > At the heart of what you need here is CLARITY. > > You need to CLEARLY communicate what it is you're doing so busy maintainers > can examine it. That's the _only_ way you're going to get something like > this merged. > > The LLM-generated code is so awful that ain't nobody got the time to try to > understand what it's doing. Indeed. > The workload for this really has to be on submitters, not maintainers. > > And what you've done, even if not intended, is workslopping, and that's > really not acceptable. Quoting the kernel process on tool-generated content > [6]: > > "If tools permit you to generate a contribution automatically, expect > additional scrutiny in proportion to how much of it was generated. > > As with the output of any tooling, the result may be incorrect or > inappropriate. You are expected to understand and to be able to defend > everything you submit. If you are unable to do so, then do not submit the > resulting changes. > > If you do so anyway, maintainers are entitled to reject your series without > detailed review." > > As per this and my previous reply, AI slop doesn't scale, even as an RFC - > I won't have time to reply like this in future, and we will just have to > reject your series out of hand, which helps nobody. True. Thanks a lot for going out of your way on this! >> >> >> -- >> All Rights Reversed. > > Thanks, Lorenzo > > [0]:https://lore.kernel.org/all/[email protected]/ > [1]:https://lore.kernel.org/linux-mm/[email protected]/ > [2]:https://lore.kernel.org/all/[email protected]/ > [3]:https://lore.kernel.org/all/[email protected]/ > [4]:https://lore.kernel.org/all/[email protected]/ > [5]:https://lore.kernel.org/all/[email protected]/ > [6]:https://docs.kernel.org/process/generated-content.html
