Re: [PATCH 10/12] sched: Add locking comments to sched_class methods

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Oct 08, 2025 at 11:43:21AM +0200, Juri Lelli wrote:
> On 08/10/25 09:33, Greg Kroah-Hartman wrote:
> > On Wed, Oct 08, 2025 at 09:04:19AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 07, 2025 at 11:54:18AM +0200, Juri Lelli wrote:
> > > 
> > > > Not for this patch, but I wondered if, while we are at it, we wanted to
> > > > complete documentation of these flags. My new AI friend is suggesting
> > > > the following, is it very much garbage? :)
> > > 
> > > Heh; its not terrible. I've been playing with local LLMs, but mostly
> > > I've found they struggle with getting enough context to not be utterly
> > > demented. And when you up the context window, they get unusable slow :/
> > > 
> > > Setting up and configuring the whole pile of subtly interlocking stacks
> > > of software to get anything useful out of this stuff is non-trivial (it
> > > reminds me of the sendmail m4 days).
> > > 
> > > > ---
> > > > 
> > > > From: Claude <claude-sonnet-4-5@anthropic.com>
> > > > Date: Mon, 7 Oct 2025 12:44:13 +0200
> > > > Subject: sched: Document remaining DEQUEUE/ENQUEUE flags
> > > > 
> > > > Complete the flag documentation by adding descriptions for the three
> > > > previously undocumented flags: DEQUEUE_SPECIAL, DEQUEUE_THROTTLE, and
> > > > ENQUEUE_INITIAL.
> > > > 
> > > > DEQUEUE_SPECIAL is used when dequeuing tasks in special states (stopped,
> > > > traced, parked, dead, or frozen) that don't use the normal wait-loop
> > > > pattern and must not use delayed dequeue.
> > > > 
> > > > DEQUEUE_THROTTLE is used when removing tasks from the runqueue due to
> > > > CFS bandwidth throttling, preventing delayed dequeue to ensure proper
> > > > throttling behavior.
> > > > 
> > > > ENQUEUE_INITIAL is used when enqueueing newly created tasks in
> > > > wake_up_new_task(), allowing the fair scheduler to give them preferential
> > > > initial placement (half vslice when PLACE_DEADLINE_INITIAL is enabled).
> > > > 
> > > > Signed-off-by: Claude <claude-sonnet-4-5@anthropic.com>
> > > > Not-so-sure-yet: Juri Lelli <juri.lelli@redhat.com>
> > > 
> > > Is this the generally acceptable form of attribution for these things?
> > > I'm not sure what the official guidance is on using these AI tools.
> > > 
> > > Greg, you have any insights here?
> > 
> > First off, Claude can NOT sign off on anything, so that's a non-starter.
> > All Red Hat people should know that :)
> 
> Yep, knew that. But I felt guilty nontheless as I didn't touch the
> change at all. Current SoB was kind of a (silly) joke. :)
> 
> > Otherwise, there is a draft of something that was going to address stuff
> > like this floating around by Dave Hansen, I'll go poke him to see what
> > the status of that is.
> 
> I believe it was suggested something like Co-developed-by: <model> and
> then Signed-off-by: <human>, but indeed curious to know how that
> discussion ended.

The general answer is "you better know the copyright ownership
information of the output of the tool you use" before you do anything
with any of these tools.  Be careful about this, because adding your
signed-off-by to a patch like makes it your responsibility :)

After that, treat it like any other tool that you use to generate a
patch, document what you used and why/how, and you should be fine.  You
have to do this today if you were to use any type of tool, so in that
way, "AI" is no different, with the exception of the ownership of the
output result (again, consult the terms of the tool used.)

Hopefully documentation updates to our process documents will reflect
this in the near future.

thanks,

greg k-h