In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
copy all segments from vmalloced memory to kernel boot memory,
because of disabled mmu.
We introduce quick kexec to save time of copying memory as above,
just like kdump(kexec on crash), by using reserved memory
"Quick Kexec".
Constructing quick kimage as the same as crash kernel,
then simply copy all segments of kimage to reserved memroy.
We also add this support in syscall kexec_load using flags
of KEXEC_QUICK.
Signed-off-by: Sang Yan <[email protected]>
---
arch/Kconfig | 10 ++++++++++
include/linux/ioport.h | 3 +++
include/linux/kexec.h | 13 +++++++++++-
include/uapi/linux/kexec.h | 3 +++
kernel/kexec.c | 10 ++++++++++
kernel/kexec_core.c | 41 +++++++++++++++++++++++++++++---------
6 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 3329fa143637..eca782cb8e29 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -21,6 +21,16 @@ config KEXEC_CORE
config KEXEC_ELF
bool
+config QUICK_KEXEC
+ bool "Support for quick kexec"
+ depends on KEXEC_CORE
+ help
+ Say y here to enable this feature.
+ It use reserved memory to accelerate kexec, just like crash
+ kexec, load new kernel and initrd to reserved memory, and
+ boot new kernel on that memory. It will save the time of
+ relocating kernel.
+
config HAVE_IMA_KEXEC
bool
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6c2b06fe8beb..f37c632accbe 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -136,6 +136,9 @@ enum {
IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
IORES_DESC_RESERVED = 7,
IORES_DESC_SOFT_RESERVED = 8,
+#ifdef CONFIG_QUICK_KEXEC
+ IORES_DESC_QUICK_KEXEC = 9,
+#endif
};
/*
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 9e93bef52968..976bf9631070 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -269,9 +269,12 @@ struct kimage {
unsigned long control_page;
/* Flags to indicate special processing */
- unsigned int type : 1;
+ unsigned int type : 2;
#define KEXEC_TYPE_DEFAULT 0
#define KEXEC_TYPE_CRASH 1
+#ifdef CONFIG_QUICK_KEXEC
+#define KEXEC_TYPE_QUICK 2
+#endif
unsigned int preserve_context : 1;
/* If set, we are using file mode kexec syscall */
unsigned int file_mode:1;
@@ -331,6 +334,11 @@ extern int kexec_load_disabled;
#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)
#endif
+#ifdef CONFIG_QUICK_KEXEC
+#undef KEXEC_FLAGS
+#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_QUICK)
+#endif
+
/* List of defined/legal kexec file flags */
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
@@ -340,6 +348,9 @@ extern int kexec_load_disabled;
extern struct resource crashk_res;
extern struct resource crashk_low_res;
extern note_buf_t __percpu *crash_notes;
+#ifdef CONFIG_QUICK_KEXEC
+extern struct resource quick_kexec_res;
+#endif
/* flag to track if kexec reboot is in progress */
extern bool kexec_in_progress;
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 05669c87a0af..e3213614b713 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -12,6 +12,9 @@
/* kexec flags for different usage scenarios */
#define KEXEC_ON_CRASH 0x00000001
#define KEXEC_PRESERVE_CONTEXT 0x00000002
+#ifdef CONFIG_QUICK_KEXEC
+#define KEXEC_QUICK 0x00000004
+#endif
#define KEXEC_ARCH_MASK 0xffff0000
/*
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f977786fe498..428af4cd3e1a 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -44,6 +44,9 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
int ret;
struct kimage *image;
bool kexec_on_panic = flags & KEXEC_ON_CRASH;
+#ifdef CONFIG_QUICK_KEXEC
+ bool kexec_on_quick = flags & KEXEC_QUICK;
+#endif
if (kexec_on_panic) {
/* Verify we have a valid entry point */
@@ -69,6 +72,13 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
image->type = KEXEC_TYPE_CRASH;
}
+#ifdef CONFIG_QUICK_KEXEC
+ if (kexec_on_quick) {
+ image->control_page = quick_kexec_res.start;
+ image->type = KEXEC_TYPE_QUICK;
+ }
+#endif
+
ret = sanity_check_segment_list(image);
if (ret)
goto out_free_image;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c19c0dad1ebe..b73dd749368b 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -70,6 +70,16 @@ struct resource crashk_low_res = {
.desc = IORES_DESC_CRASH_KERNEL
};
+#ifdef CONFIG_QUICK_KEXEC
+struct resource quick_kexec_res = {
+ .name = "Quick kexec",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ .desc = IORES_DESC_QUICK_KEXEC
+};
+#endif
+
int kexec_should_crash(struct task_struct *p)
{
/*
@@ -413,8 +423,10 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
return pages;
}
-static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
- unsigned int order)
+
+static struct page *kimage_alloc_special_control_pages(struct kimage *image,
+ unsigned int order,
+ unsigned long end)
{
/* Control pages are special, they are the intermediaries
* that are needed while we copy the rest of the pages
@@ -444,7 +456,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
size = (1 << order) << PAGE_SHIFT;
hole_start = (image->control_page + (size - 1)) & ~(size - 1);
hole_end = hole_start + size - 1;
- while (hole_end <= crashk_res.end) {
+ while (hole_end <= end) {
unsigned long i;
cond_resched();
@@ -479,7 +491,6 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
return pages;
}
-
struct page *kimage_alloc_control_pages(struct kimage *image,
unsigned int order)
{
@@ -490,8 +501,15 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
pages = kimage_alloc_normal_control_pages(image, order);
break;
case KEXEC_TYPE_CRASH:
- pages = kimage_alloc_crash_control_pages(image, order);
+ pages = kimage_alloc_special_control_pages(image, order,
+ crashk_res.end);
+ break;
+#ifdef CONFIG_QUICK_KEXEC
+ case KEXEC_TYPE_QUICK:
+ pages = kimage_alloc_special_control_pages(image, order,
+ quick_kexec_res.end);
break;
+#endif
}
return pages;
@@ -847,11 +865,11 @@ static int kimage_load_normal_segment(struct kimage *image,
return result;
}
-static int kimage_load_crash_segment(struct kimage *image,
+static int kimage_load_special_segment(struct kimage *image,
struct kexec_segment *segment)
{
- /* For crash dumps kernels we simply copy the data from
- * user space to it's destination.
+ /* For crash dumps kernels and quick kexec kernels
+ * we simply copy the data from user space to it's destination.
* We do things a page at a time for the sake of kmap.
*/
unsigned long maddr;
@@ -925,8 +943,13 @@ int kimage_load_segment(struct kimage *image,
result = kimage_load_normal_segment(image, segment);
break;
case KEXEC_TYPE_CRASH:
- result = kimage_load_crash_segment(image, segment);
+ result = kimage_load_special_segment(image, segment);
+ break;
+#ifdef CONFIG_QUICK_KEXEC
+ case KEXEC_TYPE_QUICK:
+ result = kimage_load_special_segment(image, segment);
break;
+#endif
}
return result;
--
2.19.1
On 08/14/20 at 01:52am, Sang Yan wrote:
> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> copy all segments from vmalloced memory to kernel boot memory,
> because of disabled mmu.
It is not the case on all archs, I assume your case is arm64, please
describe it in patch log :)
About the arm64 problem, I know Pavel Tatashin is working on a patchset
to improve the performance with enabling mmu.
I added Pavel in cc, can you try his patches?
>
> We introduce quick kexec to save time of copying memory as above,
> just like kdump(kexec on crash), by using reserved memory
> "Quick Kexec".
This approach may have gain, but it also introduce extra requirements to
pre-reserve a memory region. I wonder how Eric thinks about the idea.
Anyway the "quick" name sounds not very good, I would suggest do not
introduce a new param, and the code can check if pre-reserved region
exist then use it, if not then fallback to old way.
>
> Constructing quick kimage as the same as crash kernel,
> then simply copy all segments of kimage to reserved memroy.
>
> We also add this support in syscall kexec_load using flags
> of KEXEC_QUICK.
>
> Signed-off-by: Sang Yan <[email protected]>
> ---
> arch/Kconfig | 10 ++++++++++
> include/linux/ioport.h | 3 +++
> include/linux/kexec.h | 13 +++++++++++-
> include/uapi/linux/kexec.h | 3 +++
> kernel/kexec.c | 10 ++++++++++
> kernel/kexec_core.c | 41 +++++++++++++++++++++++++++++---------
> 6 files changed, 70 insertions(+), 10 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 3329fa143637..eca782cb8e29 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -21,6 +21,16 @@ config KEXEC_CORE
> config KEXEC_ELF
> bool
>
> +config QUICK_KEXEC
> + bool "Support for quick kexec"
> + depends on KEXEC_CORE
> + help
> + Say y here to enable this feature.
> + It use reserved memory to accelerate kexec, just like crash
> + kexec, load new kernel and initrd to reserved memory, and
> + boot new kernel on that memory. It will save the time of
> + relocating kernel.
> +
> config HAVE_IMA_KEXEC
> bool
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 6c2b06fe8beb..f37c632accbe 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -136,6 +136,9 @@ enum {
> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
> IORES_DESC_RESERVED = 7,
> IORES_DESC_SOFT_RESERVED = 8,
> +#ifdef CONFIG_QUICK_KEXEC
> + IORES_DESC_QUICK_KEXEC = 9,
> +#endif
> };
>
> /*
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9e93bef52968..976bf9631070 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -269,9 +269,12 @@ struct kimage {
> unsigned long control_page;
>
> /* Flags to indicate special processing */
> - unsigned int type : 1;
> + unsigned int type : 2;
> #define KEXEC_TYPE_DEFAULT 0
> #define KEXEC_TYPE_CRASH 1
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_TYPE_QUICK 2
> +#endif
> unsigned int preserve_context : 1;
> /* If set, we are using file mode kexec syscall */
> unsigned int file_mode:1;
> @@ -331,6 +334,11 @@ extern int kexec_load_disabled;
> #define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)
> #endif
>
> +#ifdef CONFIG_QUICK_KEXEC
> +#undef KEXEC_FLAGS
> +#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_QUICK)
> +#endif
> +
> /* List of defined/legal kexec file flags */
> #define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
> KEXEC_FILE_NO_INITRAMFS)
> @@ -340,6 +348,9 @@ extern int kexec_load_disabled;
> extern struct resource crashk_res;
> extern struct resource crashk_low_res;
> extern note_buf_t __percpu *crash_notes;
> +#ifdef CONFIG_QUICK_KEXEC
> +extern struct resource quick_kexec_res;
> +#endif
>
> /* flag to track if kexec reboot is in progress */
> extern bool kexec_in_progress;
> diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> index 05669c87a0af..e3213614b713 100644
> --- a/include/uapi/linux/kexec.h
> +++ b/include/uapi/linux/kexec.h
> @@ -12,6 +12,9 @@
> /* kexec flags for different usage scenarios */
> #define KEXEC_ON_CRASH 0x00000001
> #define KEXEC_PRESERVE_CONTEXT 0x00000002
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_QUICK 0x00000004
> +#endif
> #define KEXEC_ARCH_MASK 0xffff0000
>
> /*
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index f977786fe498..428af4cd3e1a 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -44,6 +44,9 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
> int ret;
> struct kimage *image;
> bool kexec_on_panic = flags & KEXEC_ON_CRASH;
> +#ifdef CONFIG_QUICK_KEXEC
> + bool kexec_on_quick = flags & KEXEC_QUICK;
> +#endif
>
> if (kexec_on_panic) {
> /* Verify we have a valid entry point */
> @@ -69,6 +72,13 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
> image->type = KEXEC_TYPE_CRASH;
> }
>
> +#ifdef CONFIG_QUICK_KEXEC
> + if (kexec_on_quick) {
> + image->control_page = quick_kexec_res.start;
> + image->type = KEXEC_TYPE_QUICK;
> + }
> +#endif
> +
> ret = sanity_check_segment_list(image);
> if (ret)
> goto out_free_image;
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c19c0dad1ebe..b73dd749368b 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -70,6 +70,16 @@ struct resource crashk_low_res = {
> .desc = IORES_DESC_CRASH_KERNEL
> };
>
> +#ifdef CONFIG_QUICK_KEXEC
> +struct resource quick_kexec_res = {
> + .name = "Quick kexec",
> + .start = 0,
> + .end = 0,
> + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> + .desc = IORES_DESC_QUICK_KEXEC
> +};
> +#endif
> +
> int kexec_should_crash(struct task_struct *p)
> {
> /*
> @@ -413,8 +423,10 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
> return pages;
> }
>
> -static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
> - unsigned int order)
> +
> +static struct page *kimage_alloc_special_control_pages(struct kimage *image,
> + unsigned int order,
> + unsigned long end)
> {
> /* Control pages are special, they are the intermediaries
> * that are needed while we copy the rest of the pages
> @@ -444,7 +456,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
> size = (1 << order) << PAGE_SHIFT;
> hole_start = (image->control_page + (size - 1)) & ~(size - 1);
> hole_end = hole_start + size - 1;
> - while (hole_end <= crashk_res.end) {
> + while (hole_end <= end) {
> unsigned long i;
>
> cond_resched();
> @@ -479,7 +491,6 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
> return pages;
> }
>
> -
> struct page *kimage_alloc_control_pages(struct kimage *image,
> unsigned int order)
> {
> @@ -490,8 +501,15 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
> pages = kimage_alloc_normal_control_pages(image, order);
> break;
> case KEXEC_TYPE_CRASH:
> - pages = kimage_alloc_crash_control_pages(image, order);
> + pages = kimage_alloc_special_control_pages(image, order,
> + crashk_res.end);
> + break;
> +#ifdef CONFIG_QUICK_KEXEC
> + case KEXEC_TYPE_QUICK:
> + pages = kimage_alloc_special_control_pages(image, order,
> + quick_kexec_res.end);
> break;
> +#endif
> }
>
> return pages;
> @@ -847,11 +865,11 @@ static int kimage_load_normal_segment(struct kimage *image,
> return result;
> }
>
> -static int kimage_load_crash_segment(struct kimage *image,
> +static int kimage_load_special_segment(struct kimage *image,
> struct kexec_segment *segment)
> {
> - /* For crash dumps kernels we simply copy the data from
> - * user space to it's destination.
> + /* For crash dumps kernels and quick kexec kernels
> + * we simply copy the data from user space to it's destination.
> * We do things a page at a time for the sake of kmap.
> */
> unsigned long maddr;
> @@ -925,8 +943,13 @@ int kimage_load_segment(struct kimage *image,
> result = kimage_load_normal_segment(image, segment);
> break;
> case KEXEC_TYPE_CRASH:
> - result = kimage_load_crash_segment(image, segment);
> + result = kimage_load_special_segment(image, segment);
> + break;
> +#ifdef CONFIG_QUICK_KEXEC
> + case KEXEC_TYPE_QUICK:
> + result = kimage_load_special_segment(image, segment);
> break;
> +#endif
> }
>
> return result;
> --
> 2.19.1
>
>
> _______________________________________________
> kexec mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
>
Thanks
Dave
On 08/14/20 14:58, Dave Young wrote:
> On 08/14/20 at 01:52am, Sang Yan wrote:
>> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
>> copy all segments from vmalloced memory to kernel boot memory,
>> because of disabled mmu.
>
> It is not the case on all archs, I assume your case is arm64, please
> describe it in patch log :)
>
Yes, it's particularly obvious on arm64. I will add it to the patch log,
and test how long it takes on x86 and other arch.
> About the arm64 problem, I know Pavel Tatashin is working on a patchset
> to improve the performance with enabling mmu.
>
> I added Pavel in cc, can you try his patches?
>
Thanks for your tips, I will try these patches. @Pavel.
Disable mmu after finishing copying pages?
>>
>> We introduce quick kexec to save time of copying memory as above,
>> just like kdump(kexec on crash), by using reserved memory
>> "Quick Kexec".
>
> This approach may have gain, but it also introduce extra requirements to
> pre-reserve a memory region. I wonder how Eric thinks about the idea.
>
> Anyway the "quick" name sounds not very good, I would suggest do not
> introduce a new param, and the code can check if pre-reserved region
> exist then use it, if not then fallback to old way.
>
aha. I agree with it, but I thought it may change the old behaviors of
kexec_load.
I will update a new patch without introducing new flags and new params.
Thanks a lot.
>>
>> Constructing quick kimage as the same as crash kernel,
>> then simply copy all segments of kimage to reserved memroy.
>>
>> We also add this support in syscall kexec_load using flags
>> of KEXEC_QUICK.
>>
>> Signed-off-by: Sang Yan <[email protected]>
>> ---
>> arch/Kconfig | 10 ++++++++++
>> include/linux/ioport.h | 3 +++
>> include/linux/kexec.h | 13 +++++++++++-
>> include/uapi/linux/kexec.h | 3 +++
>> kernel/kexec.c | 10 ++++++++++
>> kernel/kexec_core.c | 41 +++++++++++++++++++++++++++++---------
>> 6 files changed, 70 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 3329fa143637..eca782cb8e29 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -21,6 +21,16 @@ config KEXEC_CORE
>> config KEXEC_ELF
>> bool
>>
>> +config QUICK_KEXEC
>> + bool "Support for quick kexec"
>> + depends on KEXEC_CORE
>> + help
>> + Say y here to enable this feature.
>> + It use reserved memory to accelerate kexec, just like crash
>> + kexec, load new kernel and initrd to reserved memory, and
>> + boot new kernel on that memory. It will save the time of
>> + relocating kernel.
>> +
>> config HAVE_IMA_KEXEC
>> bool
>>
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index 6c2b06fe8beb..f37c632accbe 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -136,6 +136,9 @@ enum {
>> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
>> IORES_DESC_RESERVED = 7,
>> IORES_DESC_SOFT_RESERVED = 8,
>> +#ifdef CONFIG_QUICK_KEXEC
>> + IORES_DESC_QUICK_KEXEC = 9,
>> +#endif
>> };
>>
>> /*
>> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
>> index 9e93bef52968..976bf9631070 100644
>> --- a/include/linux/kexec.h
>> +++ b/include/linux/kexec.h
>> @@ -269,9 +269,12 @@ struct kimage {
>> unsigned long control_page;
>>
>> /* Flags to indicate special processing */
>> - unsigned int type : 1;
>> + unsigned int type : 2;
>> #define KEXEC_TYPE_DEFAULT 0
>> #define KEXEC_TYPE_CRASH 1
>> +#ifdef CONFIG_QUICK_KEXEC
>> +#define KEXEC_TYPE_QUICK 2
>> +#endif
>> unsigned int preserve_context : 1;
>> /* If set, we are using file mode kexec syscall */
>> unsigned int file_mode:1;
>> @@ -331,6 +334,11 @@ extern int kexec_load_disabled;
>> #define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)
>> #endif
>>
>> +#ifdef CONFIG_QUICK_KEXEC
>> +#undef KEXEC_FLAGS
>> +#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_QUICK)
>> +#endif
>> +
>> /* List of defined/legal kexec file flags */
>> #define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
>> KEXEC_FILE_NO_INITRAMFS)
>> @@ -340,6 +348,9 @@ extern int kexec_load_disabled;
>> extern struct resource crashk_res;
>> extern struct resource crashk_low_res;
>> extern note_buf_t __percpu *crash_notes;
>> +#ifdef CONFIG_QUICK_KEXEC
>> +extern struct resource quick_kexec_res;
>> +#endif
>>
>> /* flag to track if kexec reboot is in progress */
>> extern bool kexec_in_progress;
>> diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
>> index 05669c87a0af..e3213614b713 100644
>> --- a/include/uapi/linux/kexec.h
>> +++ b/include/uapi/linux/kexec.h
>> @@ -12,6 +12,9 @@
>> /* kexec flags for different usage scenarios */
>> #define KEXEC_ON_CRASH 0x00000001
>> #define KEXEC_PRESERVE_CONTEXT 0x00000002
>> +#ifdef CONFIG_QUICK_KEXEC
>> +#define KEXEC_QUICK 0x00000004
>> +#endif
>> #define KEXEC_ARCH_MASK 0xffff0000
>>
>> /*
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index f977786fe498..428af4cd3e1a 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -44,6 +44,9 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>> int ret;
>> struct kimage *image;
>> bool kexec_on_panic = flags & KEXEC_ON_CRASH;
>> +#ifdef CONFIG_QUICK_KEXEC
>> + bool kexec_on_quick = flags & KEXEC_QUICK;
>> +#endif
>>
>> if (kexec_on_panic) {
>> /* Verify we have a valid entry point */
>> @@ -69,6 +72,13 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>> image->type = KEXEC_TYPE_CRASH;
>> }
>>
>> +#ifdef CONFIG_QUICK_KEXEC
>> + if (kexec_on_quick) {
>> + image->control_page = quick_kexec_res.start;
>> + image->type = KEXEC_TYPE_QUICK;
>> + }
>> +#endif
>> +
>> ret = sanity_check_segment_list(image);
>> if (ret)
>> goto out_free_image;
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index c19c0dad1ebe..b73dd749368b 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -70,6 +70,16 @@ struct resource crashk_low_res = {
>> .desc = IORES_DESC_CRASH_KERNEL
>> };
>>
>> +#ifdef CONFIG_QUICK_KEXEC
>> +struct resource quick_kexec_res = {
>> + .name = "Quick kexec",
>> + .start = 0,
>> + .end = 0,
>> + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
>> + .desc = IORES_DESC_QUICK_KEXEC
>> +};
>> +#endif
>> +
>> int kexec_should_crash(struct task_struct *p)
>> {
>> /*
>> @@ -413,8 +423,10 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>> return pages;
>> }
>>
>> -static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
>> - unsigned int order)
>> +
>> +static struct page *kimage_alloc_special_control_pages(struct kimage *image,
>> + unsigned int order,
>> + unsigned long end)
>> {
>> /* Control pages are special, they are the intermediaries
>> * that are needed while we copy the rest of the pages
>> @@ -444,7 +456,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
>> size = (1 << order) << PAGE_SHIFT;
>> hole_start = (image->control_page + (size - 1)) & ~(size - 1);
>> hole_end = hole_start + size - 1;
>> - while (hole_end <= crashk_res.end) {
>> + while (hole_end <= end) {
>> unsigned long i;
>>
>> cond_resched();
>> @@ -479,7 +491,6 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
>> return pages;
>> }
>>
>> -
>> struct page *kimage_alloc_control_pages(struct kimage *image,
>> unsigned int order)
>> {
>> @@ -490,8 +501,15 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
>> pages = kimage_alloc_normal_control_pages(image, order);
>> break;
>> case KEXEC_TYPE_CRASH:
>> - pages = kimage_alloc_crash_control_pages(image, order);
>> + pages = kimage_alloc_special_control_pages(image, order,
>> + crashk_res.end);
>> + break;
>> +#ifdef CONFIG_QUICK_KEXEC
>> + case KEXEC_TYPE_QUICK:
>> + pages = kimage_alloc_special_control_pages(image, order,
>> + quick_kexec_res.end);
>> break;
>> +#endif
>> }
>>
>> return pages;
>> @@ -847,11 +865,11 @@ static int kimage_load_normal_segment(struct kimage *image,
>> return result;
>> }
>>
>> -static int kimage_load_crash_segment(struct kimage *image,
>> +static int kimage_load_special_segment(struct kimage *image,
>> struct kexec_segment *segment)
>> {
>> - /* For crash dumps kernels we simply copy the data from
>> - * user space to it's destination.
>> + /* For crash dumps kernels and quick kexec kernels
>> + * we simply copy the data from user space to it's destination.
>> * We do things a page at a time for the sake of kmap.
>> */
>> unsigned long maddr;
>> @@ -925,8 +943,13 @@ int kimage_load_segment(struct kimage *image,
>> result = kimage_load_normal_segment(image, segment);
>> break;
>> case KEXEC_TYPE_CRASH:
>> - result = kimage_load_crash_segment(image, segment);
>> + result = kimage_load_special_segment(image, segment);
>> + break;
>> +#ifdef CONFIG_QUICK_KEXEC
>> + case KEXEC_TYPE_QUICK:
>> + result = kimage_load_special_segment(image, segment);
>> break;
>> +#endif
>> }
>>
>> return result;
>> --
>> 2.19.1
>>
>>
>> _______________________________________________
>> kexec mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>
> Thanks
> Dave
>
>
> .
>
Thanks
Sang Yan
Hi,
On 08/14/20 at 04:21pm, Sang Yan wrote:
>
>
> On 08/14/20 14:58, Dave Young wrote:
> > On 08/14/20 at 01:52am, Sang Yan wrote:
> >> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> >> copy all segments from vmalloced memory to kernel boot memory,
> >> because of disabled mmu.
> >
> > It is not the case on all archs, I assume your case is arm64, please
> > describe it in patch log :)
> >
> Yes, it's particularly obvious on arm64. I will add it to the patch log,
> and test how long it takes on x86 and other arch.
>
> > About the arm64 problem, I know Pavel Tatashin is working on a patchset
> > to improve the performance with enabling mmu.
> >
> > I added Pavel in cc, can you try his patches?
> >
> Thanks for your tips, I will try these patches. @Pavel.
> Disable mmu after finishing copying pages?
> >>
> >> We introduce quick kexec to save time of copying memory as above,
> >> just like kdump(kexec on crash), by using reserved memory
> >> "Quick Kexec".
> >
> > This approach may have gain, but it also introduce extra requirements to
> > pre-reserve a memory region. I wonder how Eric thinks about the idea.
> >
> > Anyway the "quick" name sounds not very good, I would suggest do not
> > introduce a new param, and the code can check if pre-reserved region
> > exist then use it, if not then fallback to old way.
> >
> aha. I agree with it, but I thought it may change the old behaviors of
> kexec_load.
>
> I will update a new patch without introducing new flags and new params.
Frankly I'm still not sure it is worth to introduce a new interface if the
improvement can be done in arch code like Pavel is doing. Can you try
that first?
Thanks
Dave
Sang Yan <[email protected]> writes:
> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> copy all segments from vmalloced memory to kernel boot memory,
> because of disabled mmu.
I haven't seen kexec that slow since I tested on my 16Mhz 386.
That machine has an excuse it really is slow. Anything else
that takes seconds is almost certainly slow because someone
has misconfigured things to not cache the data copied by kexec.
I humbly suggest that you fix the arm64 code so that the data gets
cached.
Eric
On Fri, Aug 14, 2020 at 7:24 AM Dave Young <[email protected]> wrote:
>
> Hi,
>
> On 08/14/20 at 04:21pm, Sang Yan wrote:
> >
> >
> > On 08/14/20 14:58, Dave Young wrote:
> > > On 08/14/20 at 01:52am, Sang Yan wrote:
> > >> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> > >> copy all segments from vmalloced memory to kernel boot memory,
> > >> because of disabled mmu.
> > >
> > > It is not the case on all archs, I assume your case is arm64, please
> > > describe it in patch log :)
> > >
> > Yes, it's particularly obvious on arm64. I will add it to the patch log,
> > and test how long it takes on x86 and other arch.
> >
> > > About the arm64 problem, I know Pavel Tatashin is working on a patchset
> > > to improve the performance with enabling mmu.
> > >
> > > I added Pavel in cc, can you try his patches?
> > >
> > Thanks for your tips, I will try these patches. @Pavel.
> > Disable mmu after finishing copying pages?
> > >>
> > >> We introduce quick kexec to save time of copying memory as above,
> > >> just like kdump(kexec on crash), by using reserved memory
> > >> "Quick Kexec".
> > >
> > > This approach may have gain, but it also introduce extra requirements to
> > > pre-reserve a memory region. I wonder how Eric thinks about the idea.
> > >
> > > Anyway the "quick" name sounds not very good, I would suggest do not
> > > introduce a new param, and the code can check if pre-reserved region
> > > exist then use it, if not then fallback to old way.
> > >
> > aha. I agree with it, but I thought it may change the old behaviors of
> > kexec_load.
> >
> > I will update a new patch without introducing new flags and new params.
>
> Frankly I'm still not sure it is worth to introduce a new interface if the
> improvement can be done in arch code like Pavel is doing. Can you try
> that first?
Hi Dave,
Thank you for including me into this discussion.
My patches will fix this issue. This is an ARM64 specific problem and
I did not see this to be performance problem on x86 during kexec
relocation. This happens because on ARM64 relocation is performed with
MMU disabled, and when MMU is disabled the caching is disabled as
well.
I have a patch series that fixes this entirely, but James Morse
(+CCed) and I still have not agreed on the final approach. We had an
off-list conversation about it, and we need to continue it in public
ML.
Here is some history:
This is the original series that I sent a year ago. It basically
proposes the same thing as this series from Sang Yan:
https://lore.kernel.org/lkml/[email protected]/
Once, I realized that with enabling MMU the relocation is issue is
gone completely, I sent a new series, and this is the latest version
of that series:
https://lore.kernel.org/lkml/[email protected]/
It has been tested in production, and several people from different
companies commented to me that they are using it as well.
After my patch series was sent out, James created a new branch in his
tree with his approach of enabling MMU without having a new VA space,
but instead re-use what the kernel has now. I have not tested that
branch yet.
Here are some comments from James Morse and the off-list discussion we had:
-------
It sounds like you are depending on write streaming mode to meet your
target performance.
This isn't even CPU specific, its cache and firmware configuration specific!
I don't think we should optimise a general purpose operating system
based on things like this.
..
I think the best approach is going to be to eliminate the relocations entirely.
...
I'm afraid I view this kexec-map thing as high-risk duct-tape over the
kexec core code
deliberately scattering the kexec payload.
I'd prefer any approach that causes the payload to be stored in-place
from the beginning
as that benefits other architectures too.
-------
It appears James is leaning to the approach of not performing
relocation at all and use what is proposed by Sang Yan and me during
my first approach for this problem. However, I have several issues
with this take, which if addressed would be OK for me.
1. The newer, more secure kexec syscall kexec_file_load(), which
allows to check the IMA integrity of the loaded file does not have a
way to specify the area in memory where to place the kernel. We are
using this syscall in production, and cannot go back to kexec_load()
for security reasons.
2. Reserving memory means wasting memory during run-time. Our machine
has only 8G of RAM, and reserving even 128M for the next kernel is an
expensive proposition. Now we start loading the next kernel after some
non essential processes are stopped, but before essential processes
are stopped for the lowest downtime possible.
3. Disabling relocation means changes in the common code, which I am
not sure actually helps any other platform beside ARM64, so I am
worried it won't be accepted into upstream.
Thank you,
Pasha
Hi!
> +config QUICK_KEXEC
> + bool "Support for quick kexec"
> + depends on KEXEC_CORE
> + help
> + Say y here to enable this feature.
?
> + It use reserved memory to accelerate kexec, just like crash
uses
> + kexec, load new kernel and initrd to reserved memory, and
> + boot new kernel on that memory. It will save the time of
> + relocating kernel.
loads a new.... boots new...
> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
> IORES_DESC_RESERVED = 7,
> IORES_DESC_SOFT_RESERVED = 8,
> +#ifdef CONFIG_QUICK_KEXEC
> + IORES_DESC_QUICK_KEXEC = 9,
> +#endif
> };
Remove ifdef.
> /*
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9e93bef52968..976bf9631070 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -269,9 +269,12 @@ struct kimage {
> unsigned long control_page;
>
> /* Flags to indicate special processing */
> - unsigned int type : 1;
> + unsigned int type : 2;
> #define KEXEC_TYPE_DEFAULT 0
> #define KEXEC_TYPE_CRASH 1
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_TYPE_QUICK 2
> +#endif
> unsigned int preserve_context : 1;
Here, too.
> +++ b/include/uapi/linux/kexec.h
> @@ -12,6 +12,9 @@
> /* kexec flags for different usage scenarios */
> #define KEXEC_ON_CRASH 0x00000001
> #define KEXEC_PRESERVE_CONTEXT 0x00000002
> +#ifdef CONFIG_QUICK_KEXEC
> +#define KEXEC_QUICK 0x00000004
> +#endif
> #define KEXEC_ARCH_MASK 0xffff0000
And here.
Pavel
Hi guys,
On 14/08/2020 20:22, Pavel Tatashin wrote:
> On Fri, Aug 14, 2020 at 7:24 AM Dave Young <[email protected]> wrote:
>> On 08/14/20 at 04:21pm, Sang Yan wrote:
>>> On 08/14/20 14:58, Dave Young wrote:
>>>> On 08/14/20 at 01:52am, Sang Yan wrote:
>>> Yes, it's particularly obvious on arm64. I will add it to the patch log,
>>> and test how long it takes on x86 and other arch.
Earlier versions of kexec-tools had the in-purgatory checksum enabled unconditionally.
More recent versions let you disable it, I think the parameter is called no-checks. This
saves some time, but the relocations still have to be done.
>>>> About the arm64 problem, I know Pavel Tatashin is working on a patchset
>>>> to improve the performance with enabling mmu.
>>>>
>>>> I added Pavel in cc, can you try his patches?
>>>>
>>> Thanks for your tips, I will try these patches. @Pavel.
>>> Disable mmu after finishing copying pages?
>>>>> We introduce quick kexec to save time of copying memory as above,
>>>>> just like kdump(kexec on crash), by using reserved memory
>>>>> "Quick Kexec".
>>>>
>>>> This approach may have gain, but it also introduce extra requirements to
>>>> pre-reserve a memory region. I wonder how Eric thinks about the idea.
>>>>
>>>> Anyway the "quick" name sounds not very good, I would suggest do not
>>>> introduce a new param, and the code can check if pre-reserved region
>>>> exist then use it, if not then fallback to old way.
>>>>
>>> aha. I agree with it, but I thought it may change the old behaviors of
>>> kexec_load.
>>>
>>> I will update a new patch without introducing new flags and new params.
>>
>> Frankly I'm still not sure it is worth to introduce a new interface if the
>> improvement can be done in arch code like Pavel is doing. Can you try
>> that first?
> My patches will fix this issue. This is an ARM64 specific problem and
> I did not see this to be performance problem on x86 during kexec
> relocation. This happens because on ARM64 relocation is performed with
> MMU disabled, and when MMU is disabled the caching is disabled as
> well.
> I have a patch series that fixes this entirely, but James Morse
> (+CCed) and I still have not agreed on the final approach. We had an
> off-list conversation about it, and we need to continue it in public
> ML.
>
> Here is some history:
>
> This is the original series that I sent a year ago. It basically
> proposes the same thing as this series from Sang Yan:
> https://lore.kernel.org/lkml/[email protected]/
>
> Once, I realized that with enabling MMU the relocation is issue is
> gone completely, I sent a new series, and this is the latest version
> of that series:
> https://lore.kernel.org/lkml/[email protected]/
>
> It has been tested in production, and several people from different
> companies commented to me that they are using it as well.
>
> After my patch series was sent out, James created a new branch in his
> tree with his approach of enabling MMU without having a new VA space,
> but instead re-use what the kernel has now. I have not tested that
> branch yet.
For context, that is here:
http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/kexec%2Bmmu/v0
I think we can maintain this approach, but it doesn't work for Pavel, as he has extra
requirements. I stopped looking at it because it became a solution no-one needed.
> Here are some comments from James Morse and the off-list discussion we had:
> -------
> It sounds like you are depending on write streaming mode to meet your
> target performance.
> This isn't even CPU specific, its cache and firmware configuration specific!
> I don't think we should optimise a general purpose operating system
> based on things like this.
> ..
> I think the best approach is going to be to eliminate the relocations entirely.> ...
> I'm afraid I view this kexec-map thing as high-risk duct-tape over the
> kexec core code
> deliberately scattering the kexec payload.
> I'd prefer any approach that causes the payload to be stored in-place
> from the beginning
> as that benefits other architectures too.
> -------
The 'eliminate relocations' comment goes with some of the context you removed.
> It appears James is leaning to the approach of not performing
> relocation at all and use what is proposed by Sang Yan and me during
> my first approach for this problem.
The background to that is Pavel's timing requirements: Enabling the MMU isn't enough, from
his description he also depends on re-arranging the memory so the CPU only sees increasing
virtual addresses. This is what my 'write streaming' comment refers to.
Doing this requires rewriting the relocation assembly code.
If we enable the MMU during kexec relocation, I expect someone on a memory constrained
system to come out of the woodwork screaming 'regression'. Systems with insufficient
memory to allocate the page tables will no longer be able to kexec.
If we keep the relocation assembly code as it is, its possible for it to handle MMU-on and
MMU-off relocations with a very small adjustment. It just won't work for Pavel, as
enabling the MMU is not enough.
I'm confident we won't get a second copy of the relocation code, that only runs on some
platforms, past the arch code maintainer.
> However, I have several issues
> with this take, which if addressed would be OK for me.
> 1. The newer, more secure kexec syscall kexec_file_load(), which
> allows to check the IMA integrity of the loaded file does not have a
> way to specify the area in memory where to place the kernel. We are
> using this syscall in production, and cannot go back to kexec_load()
> for security reasons.
> 2. Reserving memory means wasting memory during run-time. Our machine
> has only 8G of RAM, and reserving even 128M
You're loading a 128M kernel!?
> for the next kernel is an
> expensive proposition. Now we start loading the next kernel after some
> non essential processes are stopped, but before essential processes
> are stopped for the lowest downtime possible.
> 3. Disabling relocation means changes in the common code, which I am
> not sure actually helps any other platform beside ARM64, so I am
> worried it won't be accepted into upstream.
I'm happy to post the MMU-enabled series, it needs to be maintainable and solve someone's
problem.
To chip away at the rest of Pavel's problem, my suggestions were:
* Allocate things in place. If we can allocate any 2MB hugepage, we can place the DTB
there and not need to relocate it.
* use huge pages more generally in the core code. With the MMU enabled, this might keep
the core in write-streaming-mode for longer. (might, because this is very platform
specific).
* Store the kexec payload in the crashkernel carveout, to eliminate the relocations
completely. This is the bit Pavel quoted.
To expand on the carveout:
The crashkernel carveout is sized to load the payload, and memory to run the kdump kernel
entirely from within the carveout. Its obviously bigger than the payload it contains.
If you load your kexec kernel into the 'memory' part of the carveout, it won't overwrite
the kdump payload, and it wont require relocation, as its already stored in place. arm64's
arch code will spot these in-place buffers, and skip the relocation.
If you kdump even after doing this, the kdump kernel sees the kexec payload as
uninitialised memory, and will overwrite it.
If we did this, we wouldn't need to enable the MMU, and it should skip most of the
relocation code on all architectures without any changes to the arch code.
On arm64 the kernel and initramfs only need relocating because their physical addresses
are baked into the DTB. The DTB's physical address is then passed to the new kernel.
From memory: 'relocatable kernel' is detectable from the image header, and the support
predates arm64's kexec support.
James
On 8/17/2020 9:42 PM, Pavel Machek wrote:
> Hi!
>
>> +config QUICK_KEXEC
>> + bool "Support for quick kexec"
>> + depends on KEXEC_CORE
>> + help
>> + Say y here to enable this feature.
>
> ?
>
>> + It use reserved memory to accelerate kexec, just like crash
>
> uses
>
>> + kexec, load new kernel and initrd to reserved memory, and
>> + boot new kernel on that memory. It will save the time of
>> + relocating kernel.
>
> loads a new.... boots new...
>
>> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
>> IORES_DESC_RESERVED = 7,
>> IORES_DESC_SOFT_RESERVED = 8,
>> +#ifdef CONFIG_QUICK_KEXEC
>> + IORES_DESC_QUICK_KEXEC = 9,
>> +#endif
>> };
>
> Remove ifdef.
>
>> /*
>> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
>> index 9e93bef52968..976bf9631070 100644
>> --- a/include/linux/kexec.h
>> +++ b/include/linux/kexec.h
>> @@ -269,9 +269,12 @@ struct kimage {
>> unsigned long control_page;
>>
>> /* Flags to indicate special processing */
>> - unsigned int type : 1;
>> + unsigned int type : 2;
>> #define KEXEC_TYPE_DEFAULT 0
>> #define KEXEC_TYPE_CRASH 1
>> +#ifdef CONFIG_QUICK_KEXEC
>> +#define KEXEC_TYPE_QUICK 2
>> +#endif
>> unsigned int preserve_context : 1;
>
> Here, too.
>
>> +++ b/include/uapi/linux/kexec.h
>> @@ -12,6 +12,9 @@
>> /* kexec flags for different usage scenarios */
>> #define KEXEC_ON_CRASH 0x00000001
>> #define KEXEC_PRESERVE_CONTEXT 0x00000002
>> +#ifdef CONFIG_QUICK_KEXEC
>> +#define KEXEC_QUICK 0x00000004
>> +#endif
>> #define KEXEC_ARCH_MASK 0xffff0000
>
> And here.
>
> Pavel
>
> .
>
Thanks a lot for your review.
Sang Yan.
On 08/17/20 at 01:14pm, James Morse wrote:
> Hi guys,
>
> On 14/08/2020 20:22, Pavel Tatashin wrote:
> > On Fri, Aug 14, 2020 at 7:24 AM Dave Young <[email protected]> wrote:
> >> On 08/14/20 at 04:21pm, Sang Yan wrote:
> >>> On 08/14/20 14:58, Dave Young wrote:
> >>>> On 08/14/20 at 01:52am, Sang Yan wrote:
> >>> Yes, it's particularly obvious on arm64. I will add it to the patch log,
> >>> and test how long it takes on x86 and other arch.
>
> Earlier versions of kexec-tools had the in-purgatory checksum enabled unconditionally.
> More recent versions let you disable it, I think the parameter is called no-checks. This
> saves some time, but the relocations still have to be done.
>
>
> >>>> About the arm64 problem, I know Pavel Tatashin is working on a patchset
> >>>> to improve the performance with enabling mmu.
> >>>>
> >>>> I added Pavel in cc, can you try his patches?
> >>>>
> >>> Thanks for your tips, I will try these patches. @Pavel.
> >>> Disable mmu after finishing copying pages?
>
> >>>>> We introduce quick kexec to save time of copying memory as above,
> >>>>> just like kdump(kexec on crash), by using reserved memory
> >>>>> "Quick Kexec".
> >>>>
> >>>> This approach may have gain, but it also introduce extra requirements to
> >>>> pre-reserve a memory region. I wonder how Eric thinks about the idea.
> >>>>
> >>>> Anyway the "quick" name sounds not very good, I would suggest do not
> >>>> introduce a new param, and the code can check if pre-reserved region
> >>>> exist then use it, if not then fallback to old way.
> >>>>
> >>> aha. I agree with it, but I thought it may change the old behaviors of
> >>> kexec_load.
> >>>
> >>> I will update a new patch without introducing new flags and new params.
> >>
> >> Frankly I'm still not sure it is worth to introduce a new interface if the
> >> improvement can be done in arch code like Pavel is doing. Can you try
> >> that first?
>
> > My patches will fix this issue. This is an ARM64 specific problem and
> > I did not see this to be performance problem on x86 during kexec
> > relocation. This happens because on ARM64 relocation is performed with
> > MMU disabled, and when MMU is disabled the caching is disabled as
> > well.
>
> > I have a patch series that fixes this entirely, but James Morse
> > (+CCed) and I still have not agreed on the final approach. We had an
> > off-list conversation about it, and we need to continue it in public
> > ML.
> >
> > Here is some history:
> >
> > This is the original series that I sent a year ago. It basically
> > proposes the same thing as this series from Sang Yan:
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > Once, I realized that with enabling MMU the relocation is issue is
> > gone completely, I sent a new series, and this is the latest version
> > of that series:
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > It has been tested in production, and several people from different
> > companies commented to me that they are using it as well.
> >
> > After my patch series was sent out, James created a new branch in his
> > tree with his approach of enabling MMU without having a new VA space,
> > but instead re-use what the kernel has now. I have not tested that
> > branch yet.
>
> For context, that is here:
> http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/kexec%2Bmmu/v0
>
> I think we can maintain this approach, but it doesn't work for Pavel, as he has extra
> requirements. I stopped looking at it because it became a solution no-one needed.
>
>
> > Here are some comments from James Morse and the off-list discussion we had:
> > -------
> > It sounds like you are depending on write streaming mode to meet your
> > target performance.
> > This isn't even CPU specific, its cache and firmware configuration specific!
> > I don't think we should optimise a general purpose operating system
> > based on things like this.
> > ..
> > I think the best approach is going to be to eliminate the relocations entirely.> ...
> > I'm afraid I view this kexec-map thing as high-risk duct-tape over the
> > kexec core code
> > deliberately scattering the kexec payload.
> > I'd prefer any approach that causes the payload to be stored in-place
> > from the beginning
> > as that benefits other architectures too.
> > -------
>
> The 'eliminate relocations' comment goes with some of the context you removed.
>
>
> > It appears James is leaning to the approach of not performing
> > relocation at all and use what is proposed by Sang Yan and me during
> > my first approach for this problem.
>
> The background to that is Pavel's timing requirements: Enabling the MMU isn't enough, from
> his description he also depends on re-arranging the memory so the CPU only sees increasing
> virtual addresses. This is what my 'write streaming' comment refers to.
> Doing this requires rewriting the relocation assembly code.
>
> If we enable the MMU during kexec relocation, I expect someone on a memory constrained
> system to come out of the woodwork screaming 'regression'. Systems with insufficient
> memory to allocate the page tables will no longer be able to kexec.
>
> If we keep the relocation assembly code as it is, its possible for it to handle MMU-on and
> MMU-off relocations with a very small adjustment. It just won't work for Pavel, as
> enabling the MMU is not enough.
>
> I'm confident we won't get a second copy of the relocation code, that only runs on some
> platforms, past the arch code maintainer.
>
>
> > However, I have several issues
> > with this take, which if addressed would be OK for me.
> > 1. The newer, more secure kexec syscall kexec_file_load(), which
> > allows to check the IMA integrity of the loaded file does not have a
> > way to specify the area in memory where to place the kernel. We are
> > using this syscall in production, and cannot go back to kexec_load()
> > for security reasons.
> > 2. Reserving memory means wasting memory during run-time. Our machine
> > has only 8G of RAM, and reserving even 128M
>
> You're loading a 128M kernel!?
>
>
> > for the next kernel is an
> > expensive proposition. Now we start loading the next kernel after some
> > non essential processes are stopped, but before essential processes
> > are stopped for the lowest downtime possible.
>
> > 3. Disabling relocation means changes in the common code, which I am
> > not sure actually helps any other platform beside ARM64, so I am
> > worried it won't be accepted into upstream.
>
> I'm happy to post the MMU-enabled series, it needs to be maintainable and solve someone's
> problem.
>
> To chip away at the rest of Pavel's problem, my suggestions were:
> * Allocate things in place. If we can allocate any 2MB hugepage, we can place the DTB
> there and not need to relocate it.
>
> * use huge pages more generally in the core code. With the MMU enabled, this might keep
> the core in write-streaming-mode for longer. (might, because this is very platform
> specific).
>
> * Store the kexec payload in the crashkernel carveout, to eliminate the relocations
> completely. This is the bit Pavel quoted.
>
> To expand on the carveout:
> The crashkernel carveout is sized to load the payload, and memory to run the kdump kernel
> entirely from within the carveout. Its obviously bigger than the payload it contains.
>
> If you load your kexec kernel into the 'memory' part of the carveout, it won't overwrite
> the kdump payload, and it wont require relocation, as its already stored in place. arm64's
> arch code will spot these in-place buffers, and skip the relocation.
>
> If you kdump even after doing this, the kdump kernel sees the kexec payload as
> uninitialised memory, and will overwrite it.
>
> If we did this, we wouldn't need to enable the MMU, and it should skip most of the
> relocation code on all architectures without any changes to the arch code.
I'm not very confident about this approach.
Kdump usually goes with a minimum initramfs, but for kexec reboot the
normal initramfs generated by distribution could be larger, and there
could be some other cases which can cause troubles.
Another way, maybe one can copy the kernel, dtb, initrd etc with the
very early boot code. And the later kernel code just use the kexec_file_load
function to load them, since they are already in kernel buffers so the
relocations are not necessary.
Current kexec_file_load use 'fd' to load file content, we can have some
interface to load from memory buffers.
Anyway this is just a wild idea.
>
> On arm64 the kernel and initramfs only need relocating because their physical addresses
> are baked into the DTB. The DTB's physical address is then passed to the new kernel.
> From memory: 'relocatable kernel' is detectable from the image header, and the support
> predates arm64's kexec support.
>
>
> James
>
Thanks
Dave