Hi,
在 2025/8/8 15:57, Oleg Nesterov 写道:
On 08/08, Zihuan Zhang wrote:
在 2025/8/7 21:25, Michal Hocko 写道:
If they are running in the userspace and e.g. sleeping while not
TASK_FREEZABLE then priority simply makes no difference. And if they are
TASK_FREEZABLE then the priority doens't matter either.
What am I missing?
I too do not understand how can this series improve the freezer.
Thanks for your question — actually, I just replied to Michal with a
similar explanation, but I really appreciate you raising the same point,
so let me add a bit more context here.
Right now, we're trying to address the case where certain tasks fail to
freeze (often due to short-lived D-state issues). Our current workaround
is to increase the number of freeze iterations in the next suspend
attempt for those tasks.
While this isn't a perfect solution, the overhead of a few extra
iterations is minimal compared to the cost of retrying the whole suspend
cycle due to a stuck D-state task. So for now, we believe this is a
reasonable tradeoff until we find a more deterministic way to
preemptively detect and prioritize problematic tasks.
Happy to hear your thoughts or suggestions if you think there's a better
direction to explore.
under ideal conditions, if a userspace task is TASK_FREEZABLE, receives the
freezing() signal, and enters the refrigerator in a timely manner,
Note that __freeze_task() won't even send a signal to a sleeping
TASK_FREEZABLE task, __freeze_task() will just change its state to
TASK_FROZEN.
Oleg.
You are right.
