From: james.morse@arm•com (James Morse)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 09/10] PM / Hibernate: Publish pages restored in-place to arch code
Date: Mon, 07 Dec 2015 11:28:44 +0000 [thread overview]
Message-ID: <56656D6C.5010004@arm.com> (raw)
In-Reply-To: <20151205093534.GA7569@amd>
Hi Pavel,
On 05/12/15 09:35, Pavel Machek wrote:
> On Thu 2015-11-26 17:32:47, James Morse wrote:
>> Some architectures require code written to memory as if it were data to be
>> 'cleaned' from any data caches before the processor can fetch them as new
>> instructions.
>>
>> During resume from hibernate, the snapshot code copies some pages directly,
>> meaning these architectures do not get a chance to perform their cache
>> maintenance. Create a new list of pages that were restored in place, so
>> that the arch code can perform this maintenance when necessary.
>
> Umm. Could the copy function be modified to do the neccessary
> flushing, instead?
The copying is done by load_image_lzo() using memcpy() if you have
compression enabled, and by load_image() using swap_read_page() if you
don't.
I didn't do it here as it would clean every page copied, which was the
worrying part of the previous approach. If there is an architecture
where this cache-clean operation is expensive, it would slow down
restore. I was trying to benchmark the impact of this on 32bit arm when
I spotted it was broken.
This allocated-same-page code path doesn't happen very often, so we
don't want this to have an impact on the 'normal' code path. On 32bit
arm I saw ~20 of these allocations out of ~60,000 pages.
This new way allocates a few extra pages during restore, and doesn't
assume that flush_cache_range() needs calling. It should have no impact
on architectures that aren't using the new list.
> Alternatively, can you just clean the whole cache before jumping to
> the new kernel?
On arm64, cleaning the whole cache means cleaning all of memory by
virtual address, which would be a high price to pay when we only need to
clean the pages we copied. The current implementation does clean all the
page it copies, the problem is the ~0.03% that are copied behind its
back. This patch publishes where those pages are.
Thanks!
James
next prev parent reply other threads:[~2015-12-07 11:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-26 17:32 [PATCH v3 00/10] arm64: kernel: Add support for hibernate/suspend-to-disk James Morse
2015-11-26 17:32 ` [PATCH v3 01/10] arm64: Fold proc-macros.S into assembler.h James Morse
2015-12-01 9:18 ` Pavel Machek
2015-11-26 17:32 ` [PATCH v3 02/10] arm64: Convert hcalls to use HVC immediate value James Morse
2015-11-26 17:32 ` [PATCH v3 03/10] arm64: Add new hcall HVC_CALL_FUNC James Morse
2015-11-26 17:32 ` [PATCH v3 04/10] arm64: kvm: allows kvm cpu hotplug James Morse
2015-11-26 17:32 ` [PATCH v3 05/10] arm64: kernel: Rework finisher callback out of __cpu_suspend_enter() James Morse
2015-11-26 17:32 ` [PATCH v3 06/10] arm64: Change cpu_resume() to enable mmu early then access sleep_sp by va James Morse
2015-11-26 17:32 ` [PATCH v3 07/10] arm64: kernel: Include _AC definition in page.h James Morse
2015-12-01 9:28 ` Pavel Machek
2015-11-26 17:32 ` [PATCH v3 08/10] arm64: Promote KERNEL_START/KERNEL_END definitions to a header file James Morse
2015-12-01 9:28 ` Pavel Machek
2015-11-26 17:32 ` [PATCH v3 09/10] PM / Hibernate: Publish pages restored in-place to arch code James Morse
2015-12-03 12:09 ` Lorenzo Pieralisi
2015-12-04 16:26 ` James Morse
2015-12-05 9:35 ` Pavel Machek
2015-12-07 11:28 ` James Morse [this message]
2015-12-08 8:19 ` Pavel Machek
2015-12-16 9:55 ` James Morse
2015-11-26 17:32 ` [PATCH v3 10/10] arm64: kernel: Add support for hibernate/suspend-to-disk James Morse
2015-12-01 9:31 ` Pavel Machek
2015-12-08 10:39 ` James Morse
2015-12-08 11:48 ` [PATCH] fixup! " James Morse
2015-12-15 17:42 ` [PATCH v3 10/10] " Catalin Marinas
2015-12-18 11:37 ` [ALT-PATCH v3 9/10] PM / Hibernate: Call flush_icache_range() on pages restored in-place James Morse
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=56656D6C.5010004@arm.com \
--to=james.morse@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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