Re: [RFC PATCH] PM: Optionally block user fork during freeze to improve performance

[Zihuan Zhang <zhangzihuan@kylinos.cn>]

Hi David,

在 2025/6/16 15:45, David Hildenbrand 写道:
>
>>> [...]
>> In our test scenario, although new processes can indeed be created
>> during the usleep_range() intervals between freeze iterations, it’s
>> actually difficult to make the freezer fail outright. This is because
>> user processes are forcibly frozen: when they return to user space and
>> check for pending signals, they enter try_to_freeze() and transition
>> into the refrigerator.
>>
>> However, since the scheduler is fair by design, it gives both newly
>> forked tasks and yet-to-be-frozen tasks a chance to run. This
>> competition for CPU time can slightly delay the overall freeze process.
>> While this typically doesn’t lead to failure, it does cause more retries
>> than necessary, especially under CPU pressure.
>
> I think that goes back to my original comment: why are we even 
> allowing fork children to run at all when we are currently freezing 
> all tasks?
>
> I would imagine that try_to_freeze_tasks() should force any new 
> processes (forked children) to start in the frozen state directly and 
> not get scheduled in the first place.
>
Thanks again for your comments and suggestion.

We understand the motivation behind your idea: ideally, newly forked 
tasks during freezing should either be immediately frozen or prevented 
from running at all, to avoid unnecessary retries and delays. That makes 
perfect sense.

However, implementing this seems non-trivial under the current freezer 
model, as it relies on voluntary transitions and lacks a mechanism to 
block forked children from being scheduled.

Any insights or pointers would be greatly appreciated.

Best regards,
Zihuan Zhang