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

[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.

--
Cheers,

David / dhildenb