From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Zihuan Zhang <zhangzihuan@kylinos.cn>,
pavel@kernel.org, len.brown@intel.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v3 1/1] PM / Freezer: Skip zombie/dead processes to
Date: Thu, 3 Jul 2025 18:40:21 +0200 [thread overview]
Message-ID: <20250703164021.GY1613200@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJZ5v0jpuUVM73M=Gzq36je=K_7zEkvVd8bxohi6N5OYgxgUug@mail.gmail.com>
On Thu, Jul 03, 2025 at 04:15:10PM +0200, Rafael J. Wysocki wrote:
> The patch subject appears to be incomplete.
>
> On Wed, Jun 11, 2025 at 12:13 PM Zihuan Zhang <zhangzihuan@kylinos.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@kylinos.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?
How realistic is it to have a significant amount of zombies when
freezing? This seems like an artificial corner case at best.
Zombie tasks are stuck waiting on their parent to consume their exit
state or something, right? And those parents being frozen, they pretty
much stay there.
So I suppose the logic holds, but urgh, do we really need this?
next prev parent reply other threads:[~2025-07-03 16:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 10:12 [PATCH v3 0/1] PM / Freezer: Skip zombie/dead processes to reduce Zihuan Zhang
2025-06-11 10:12 ` [PATCH v3 1/1] PM / Freezer: Skip zombie/dead processes to Zihuan Zhang
2025-07-03 14:15 ` Rafael J. Wysocki
2025-07-03 16:40 ` Peter Zijlstra [this message]
2025-07-03 17:15 ` Rafael J. Wysocki
2025-07-04 1:45 ` Zihuan Zhang
2025-07-04 8:19 ` Peter Zijlstra
2025-07-04 8:48 ` Zihuan Zhang
2025-07-04 9:21 ` Peter Zijlstra
2025-07-07 1:00 ` Zihuan Zhang
2025-07-07 8:42 ` Peter Zijlstra
2025-07-08 0:56 ` Zihuan Zhang
2025-07-16 16:16 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250703164021.GY1613200@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=zhangzihuan@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox