All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Will Deacon <will.deacon@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Kevin Kang <kkang@intrinsyc.com>,
	Geoff Levand <geoff@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	wangfei <w.f@huawei.com>, Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [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


WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2015-12-07 11:29 UTC|newest]

Thread overview: 50+ 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 ` James Morse
2015-11-26 17:32 ` [PATCH v3 01/10] arm64: Fold proc-macros.S into assembler.h James Morse
2015-11-26 17:32   ` James Morse
2015-12-01  9:18   ` Pavel Machek
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   ` 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   ` James Morse
2015-11-26 17:32 ` [PATCH v3 04/10] arm64: kvm: allows kvm cpu hotplug James Morse
2015-11-26 17:32   ` 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   ` 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   ` James Morse
2015-11-26 17:32 ` [PATCH v3 07/10] arm64: kernel: Include _AC definition in page.h James Morse
2015-11-26 17:32   ` James Morse
2015-12-01  9:28   ` Pavel Machek
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-11-26 17:32   ` James Morse
2015-12-01  9:28   ` Pavel Machek
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-11-26 17:32   ` James Morse
2015-12-03 12:09   ` Lorenzo Pieralisi
2015-12-03 12:09     ` Lorenzo Pieralisi
2015-12-04 16:26     ` James Morse
2015-12-04 16:26       ` James Morse
2015-12-05  9:35   ` Pavel Machek
2015-12-05  9:35     ` Pavel Machek
2015-12-07 11:28     ` James Morse [this message]
2015-12-07 11:28       ` James Morse
2015-12-08  8:19       ` Pavel Machek
2015-12-08  8:19         ` Pavel Machek
2015-12-16  9:55         ` James Morse
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-11-26 17:32   ` James Morse
2015-12-01  9:31   ` Pavel Machek
2015-12-01  9:31     ` Pavel Machek
2015-12-08 10:39     ` James Morse
2015-12-08 10:39       ` James Morse
2015-12-08 11:48   ` [PATCH] fixup! " James Morse
2015-12-08 11:48     ` James Morse
2015-12-15 17:42   ` [PATCH v3 10/10] " Catalin Marinas
2015-12-15 17:42     ` 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
2015-12-18 11:37   ` 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.com \
    --cc=catalin.marinas@arm.com \
    --cc=geoff@infradead.org \
    --cc=kkang@intrinsyc.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=w.f@huawei.com \
    --cc=will.deacon@arm.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.