lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jpuUVM73M=Gzq36je=K_7zEkvVd8bxohi6N5OYgxgUug@mail.gmail.com>
Date: Thu, 3 Jul 2025 16:15:10 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Zihuan Zhang <zhangzihuan@...inos.cn>, Peter Zijlstra <peterz@...radead.org>
Cc: rafael@...nel.org, pavel@...nel.org, len.brown@...el.com, 
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] PM / Freezer: Skip zombie/dead processes to

The patch subject appears to be incomplete.

On Wed, Jun 11, 2025 at 12:13 PM Zihuan Zhang <zhangzihuan@...inos.cn> wrote:
>
> When freezing user space during suspend or hibernation, the freezer
> iterates over all tasks and attempts to freeze them via
> try_to_freeze_tasks().
>
> However, zombie processes (i.e., tasks in EXIT_ZOMBIE state) are no
> longer running and will never enter the refrigerator. Trying to freeze
> them is meaningless and causes extra overhead, especially when there are
> thousands of zombies created during stress conditions such as fork
> storms.
>
> This patch skips zombie processes during the freezing phase.
>
> In our testing with ~30,000 user processes (including many zombies), the
> average freeze time during suspend (S3) dropped from ~43 ms to ~16 ms:
>
>     - Without the patch: ~43 ms average freeze latency
>     - With the patch:    ~16 ms average freeze latency
>     - Improvement:       ~62%

And what's the total suspend time on the system in question?

> This confirms that skipping zombies significantly speeds up the freezing
> process when the system is under heavy load with many short-lived tasks.
>
> Signed-off-by: Zihuan Zhang <zhangzihuan@...inos.cn>
>
> Changes in v3:
> - Added performance test
>
> Changes in v2:
> - Simplified code, added judgment of dead processes
> - Rewrite changelog
> ---
>  kernel/power/process.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index a6f7ba2d283d..2bbe22610522 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -51,7 +51,7 @@ static int try_to_freeze_tasks(bool user_only)
>                 todo = 0;
>                 read_lock(&tasklist_lock);
>                 for_each_process_thread(g, p) {
> -                       if (p == current || !freeze_task(p))
> +                       if (p == current || p->exit_state || !freeze_task(p))
>                                 continue;
>
>                         todo++;
> --

This is basically fine by me, but I wonder what other people think.

Peter?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ