Message ID | 149544568763.16888.16656118217496342159.stgit@hbathini.in.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Commit | e7467dc6947d7074417aa4cda44b851010fd0795 |
Headers | show |
On Mon, 22 May 2017 15:04:47 +0530 Hari Bathini <hbathini@linux.vnet.ibm.com> wrote: > With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset > closer to bottom of RAM"), memory for fadump is no longer reserved at > the top of RAM. But there are still a few places which say so. Change > them appropriately. > > Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> > --- > Documentation/powerpc/firmware-assisted-dump.txt | 4 ++-- > arch/powerpc/kernel/fadump.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/powerpc/firmware-assisted-dump.txt > b/Documentation/powerpc/firmware-assisted-dump.txt index > 9cabaf8..bdd344a 100644 --- > a/Documentation/powerpc/firmware-assisted-dump.txt +++ > b/Documentation/powerpc/firmware-assisted-dump.txt @@ -61,8 +61,8 @@ > as follows: boot successfully. For syntax of crashkernel= parameter, > refer to Documentation/kdump/kdump.txt. If any offset is > provided in crashkernel= parameter, it will be ignored > - as fadump reserves memory at end of RAM for boot memory > - dump preservation in case of a crash. > + as fadump uses a predefined offset to reserve memory > + for boot memory dump preservation in case of a crash. What is the reason for fadump to prefer a random offset calculated by the kernel over a random offset supplied by the user? Since the random offset calculated by the kernel was recently adjusted to counter issues with fadump registration maybe it would be reasonable to allow the user to supply a custom random offset and override the kernel-calculated random offset if they want to do so. PS 'random' meaning in no relationship to actual system topology that would warrant this offset to be in any way better than any other. Thanks Michal
Hi Michal, Thanks for the review.. On Monday 22 May 2017 04:25 PM, Michal Suchánek wrote: > On Mon, 22 May 2017 15:04:47 +0530 > Hari Bathini <hbathini@linux.vnet.ibm.com> wrote: > >> With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset >> closer to bottom of RAM"), memory for fadump is no longer reserved at >> the top of RAM. But there are still a few places which say so. Change >> them appropriately. >> >> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> >> --- >> Documentation/powerpc/firmware-assisted-dump.txt | 4 ++-- >> arch/powerpc/kernel/fadump.c | 4 ++-- >> 2 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/powerpc/firmware-assisted-dump.txt >> b/Documentation/powerpc/firmware-assisted-dump.txt index >> 9cabaf8..bdd344a 100644 --- >> a/Documentation/powerpc/firmware-assisted-dump.txt +++ >> b/Documentation/powerpc/firmware-assisted-dump.txt @@ -61,8 +61,8 @@ >> as follows: boot successfully. For syntax of crashkernel= parameter, >> refer to Documentation/kdump/kdump.txt. If any offset is >> provided in crashkernel= parameter, it will be ignored >> - as fadump reserves memory at end of RAM for boot memory >> - dump preservation in case of a crash. >> + as fadump uses a predefined offset to reserve memory >> + for boot memory dump preservation in case of a crash. > What is the reason for fadump to prefer a random offset calculated by > the kernel over a random offset supplied by the user? > An offset provided by user needs multiple checks failing which can be tricky. While implementation is still possible, it makes the code complicated for no practical gain as commit f6e6bedb7731 is already calculating the best possible offset.. Thanks Hari
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt index 9cabaf8..bdd344a 100644 --- a/Documentation/powerpc/firmware-assisted-dump.txt +++ b/Documentation/powerpc/firmware-assisted-dump.txt @@ -61,8 +61,8 @@ as follows: boot successfully. For syntax of crashkernel= parameter, refer to Documentation/kdump/kdump.txt. If any offset is provided in crashkernel= parameter, it will be ignored - as fadump reserves memory at end of RAM for boot memory - dump preservation in case of a crash. + as fadump uses a predefined offset to reserve memory + for boot memory dump preservation in case of a crash. -- After the low memory (boot memory) area has been saved, the firmware will reset PCI and other hardware state. It will diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index c0db844..63c4281 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -218,8 +218,8 @@ static inline unsigned long fadump_calculate_reserve_size(void) /* * Check if the size is specified through crashkernel= cmdline - * option. If yes, then use that but ignore base as fadump - * reserves memory at end of RAM. + * option. If yes, then use that but ignore base as fadump reserves + * memory at a predefined offset. */ ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), &size, &base);
With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset closer to bottom of RAM"), memory for fadump is no longer reserved at the top of RAM. But there are still a few places which say so. Change them appropriately. Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> --- Documentation/powerpc/firmware-assisted-dump.txt | 4 ++-- arch/powerpc/kernel/fadump.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)