All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	kernelfans@gmail.com,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Hari Bathini <hbathini@linux.vnet.ibm.com>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Ananth Narayan <ananth@in.ibm.com>
Subject: [PATCH v5 0/4] powerpc/fadump: Improvements and fixes for firmware-assisted dump.
Date: Thu, 26 Apr 2018 17:11:56 +0530	[thread overview]
Message-ID: <152474278043.5697.2553982145593952228.stgit@jupiter.in.ibm.com> (raw)

One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. This reserved
memory is used for saving the contents of old crashed kernel's memory before
fadump capture kernel uses old kernel's memory area to boot. However, This
reserved memory area stays unused until system crash and isn't available
for production kernel to use.

Instead of setting aside a significant chunk of memory that nobody can use,
take advantage Linux kernel's Contiguous Memory Allocator (CMA) feature,
to reserve a significant chunk of memory that the kernel is prevented from
using , but applications are free to use it.

Patch 2 implements the usage of CMA region to allow production kernel to
use that memory for applications usage, making fadump reservationless.
We now initialize siginificant chunk of faump reserved memory for CMA.
Patch 1, 3 and 4 fixes various fadump issues and bugs.

Changes in V5:
- Drop the patch that does metadata movement.
- Move the kexec fix patch to top (patch 1)
- Fold CMA documenation patch into patch 2
- Fix the compilation issues when CONFIG_CMA is not set. Reported by Hari.
- Use the approach of using boot memory size for CMA as suggested by Hari
  except the movement of sections. Thanks to Hari.

Changes in V4:
- patch 1: Make fadump compatible irrespective of kernel versions.
- patch 4: moved out of the series and been posted seperatly at
  http://patchwork.ozlabs.org/patch/896716/
- Documentation update about CMA reservation.

Changes in V3:
- patch 1 & 2: move metadata region and documentation update.
- patch 7: Un-register the faudmp on kexec path


---

Mahesh Salgaonkar (4):
      powerpc/fadump: un-register fadump on kexec path.
      powerpc/fadump: Reservationless firmware assisted dump
      powerpc/fadump: throw proper error message on fadump registration failure.
      powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.


 Documentation/powerpc/firmware-assisted-dump.txt |   10 ++
 arch/powerpc/include/asm/fadump.h                |    6 +
 arch/powerpc/kernel/fadump.c                     |  130 ++++++++++++++++++++--
 arch/powerpc/platforms/pseries/hotplug-memory.c  |    7 +
 4 files changed, 137 insertions(+), 16 deletions(-)

--
Signature

             reply	other threads:[~2018-04-26 11:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 11:41 Mahesh J Salgaonkar [this message]
2018-04-26 11:42 ` [PATCH v5 1/4] powerpc/fadump: un-register fadump on kexec path Mahesh J Salgaonkar
2018-04-26 12:58   ` Nicholas Piggin
2018-04-26 13:05     ` Mahesh Jagannath Salgaonkar
2018-04-26 13:40       ` Nicholas Piggin
2018-04-27  6:25         ` Mahesh Jagannath Salgaonkar
2018-04-26 11:42 ` [PATCH v5 2/4] powerpc/fadump: Reservationless firmware assisted dump Mahesh J Salgaonkar
2018-04-26 11:42 ` [PATCH v5 3/4] powerpc/fadump: throw proper error message on fadump registration failure Mahesh J Salgaonkar
2018-04-26 11:42 ` [PATCH v5 4/4] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area Mahesh J Salgaonkar

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=152474278043.5697.2553982145593952228.stgit@jupiter.in.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hbathini@linux.vnet.ibm.com \
    --cc=kernelfans@gmail.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=srikar@linux.vnet.ibm.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.