mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [scheduler] questions around scheduler, task states, etc.
@ 2025-04-14 18:00 Chris Friesen
  0 siblings, 0 replies; only message in thread
From: Chris Friesen @ 2025-04-14 18:00 UTC (permalink / raw)
  To: LKML

In do_wait(), we basically do:

add_wait_queue()
set_current_state(TASK_INTERRUPTIBLE)
__do_wait()
schedule()
__set_current_state(TASK_RUNNING)
remove_wait_queue()

Would it be valid to move the set_current_state(TASK_INTERRUPTIBLE) call 
to *after* the call to __do_wait()?   Or would that break something?

The reason I ask is that I'm working on a system (6.6 kernel with RT 
patches) that uses stalld, and it only evaluates tasks in the 
TASK_RUNNING state.  There seems to be a code path in __do_wait() where 
the code can be preempted by a high-priority CPU hog while partially 
holding tasklist_lock, and this leads to bad things because stalld 
doesn't consider the preempted task as actually being runnable due to 
the task state being TASK_INTERRUPTIBLE.

If we could defer setting the state to TASK_INTERRUPTIBLE until right 
before we call schedule(), I think that would avoid the issue.

I'm not currently subscribed to the list, so please CC me on replies.

Thanks,
Chris Friesen

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-04-14 18:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-04-14 18:00 [scheduler] questions around scheduler, task states, etc Chris Friesen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®