* [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®