From: Matthew Leach <matthew.leach@collabora.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Machek <pavel@kernel.org>, Len Brown <lenb@kernel.org>,
Mario Limonciello <mario.limonciello@amd.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
YoungJun Park <youngjun.park@lge.com>,
kernel@collabora.com
Subject: Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare
Date: Mon, 13 Apr 2026 10:12:03 +0100 [thread overview]
Message-ID: <87mrz78brw.fsf@collabora.com> (raw)
In-Reply-To: <CAJZ5v0j7fqyL2GtWzwpWP8ATj=WnuQGC5z8Zhz7VO-jixrYnpA@mail.gmail.com> (Rafael J. Wysocki's message of "Mon, 6 Apr 2026 17:11:41 +0200")
Hi Rafael,
"Rafael J. Wysocki" <rafael@kernel.org> writes:
> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
> <matthew.leach@collabora.com> wrote:
>>
[...]
> Can you please have a look at
>
> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
[pasting comment in-line here for comment]
> Does this relocation introduce a deadlock during memory reclaim?
>
> hibernate_preallocate_memory() allocates a large amount of memory and
> triggers direct reclaim. Direct reclaim needs to write back dirty file
> pages and swap out anonymous pages.
>
> Since freeze_kernel_threads() just ran, threads required for I/O
> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
> currently frozen. Will the I/O for page reclaim block indefinitely
> waiting on these frozen threads?
The existing code already performs a memory reclaim after
freeze_kernel_threads(). The old shrink_shmem_memory() called
shrink_all_memory() in the same position, after both
freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
being introduced by this patch.
Nevertheless, the call chain looks like:
shrink_all_memory()
-> do_try_to_free_pages()
-> shrink_zones()
-> shrink_node()
-> shrink_folio_list()
-> pageout()
pageout() only writes back shmem and anonymous folios to swap; so jdb2
and other FS threads being frozen isn't a concern. For the swap write
out, the I/O submission path is via submit_bio() which is also
synchronous.
> Additionally, because the OOM killer is already disabled by
> freeze_processes() earlier in the hibernation path, can the reclaim path
> get stuck permanently without being able to fall back to killing
> processes?
There's nothing new here regarding the OOM killer. freeze_processes()
disables it in hibernate() prior to calling hibernation_snapshot().
Since this patch is entirely contained within hibernation_snapshot()
that pattern hasn't changed.
Regards,
--
Matt
next prev parent reply other threads:[~2026-04-13 9:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 7:36 [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare Matthew Leach
2026-04-03 13:26 ` Mario Limonciello
2026-04-06 15:11 ` Rafael J. Wysocki
2026-04-13 9:12 ` Matthew Leach [this message]
2026-05-18 13:37 ` Matthew Leach
2026-05-18 13:44 ` Rafael J. Wysocki
2026-05-20 20:27 ` Rafael J. Wysocki
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=87mrz78brw.fsf@collabora.com \
--to=matthew.leach@collabora.com \
--cc=kernel@collabora.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=youngjun.park@lge.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.