All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org
Subject: Re: [PATCH 1/3] kexec: don't invoke OOM-killer for control page allocation
Date: Mon, 18 Apr 2016 13:32:53 +0800	[thread overview]
Message-ID: <20160418053253.GA3602@x1.redhat.com> (raw)
In-Reply-To: <E1aqnQo-0001Tu-Ch@rmk-PC.arm.linux.org.uk>

On 04/14/16 at 09:00pm, Russell King wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.

Originally kexec was made to reboot to test kernel quickly. If 1st
kernel is palyed and hurted in a bad state and developer want to discard
it and take a quick reboot, why don't we have a best try to make a
successful kexec load?

I personally think this change sounds un-reasonable.

> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>  
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>  
>  #ifndef KEXEC_CONTROL_PAGE_SIZE
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org
Subject: Re: [PATCH 1/3] kexec: don't invoke OOM-killer for control page allocation
Date: Mon, 18 Apr 2016 05:32:53 +0000	[thread overview]
Message-ID: <20160418053253.GA3602@x1.redhat.com> (raw)
In-Reply-To: <E1aqnQo-0001Tu-Ch@rmk-PC.arm.linux.org.uk>

On 04/14/16 at 09:00pm, Russell King wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.

Originally kexec was made to reboot to test kernel quickly. If 1st
kernel is palyed and hurted in a bad state and developer want to discard
it and take a quick reboot, why don't we have a best try to make a
successful kexec load?

I personally think this change sounds un-reasonable.

> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>  
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>  
>  #ifndef KEXEC_CONTROL_PAGE_SIZE
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2016-04-18  5:33 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 19:59 [PATCH 0/3] Initial Kexec patches Russell King - ARM Linux
2016-04-14 19:59 ` Russell King - ARM Linux
2016-04-14 19:59 ` Russell King - ARM Linux
2016-04-14 20:00 ` [PATCH 1/3] kexec: don't invoke OOM-killer for control page allocation Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:32   ` Baoquan He [this message]
2016-04-18  5:32     ` Baoquan He
2016-04-18  8:39     ` Russell King - ARM Linux
2016-04-18  8:39       ` Russell King - ARM Linux
2016-04-18 10:12       ` Baoquan He
2016-04-18 10:12         ` Baoquan He
2016-04-28  9:53         ` Baoquan He
2016-04-28  9:53           ` Baoquan He
2016-04-14 20:00 ` [PATCH 2/3] kexec: ensure user memory sizes do not wrap Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:35   ` Baoquan He
2016-04-18  5:35     ` Baoquan He
2016-04-18  8:37     ` Russell King - ARM Linux
2016-04-18  8:37       ` Russell King - ARM Linux
2016-04-18 10:17       ` Baoquan He
2016-04-18 10:17         ` Baoquan He
2016-04-28  9:56   ` Baoquan He
2016-04-28  9:56     ` Baoquan He
2016-04-28 11:07   ` Minfei Huang
2016-04-28 11:07     ` Minfei Huang
2016-04-28 12:22     ` Russell King - ARM Linux
2016-04-28 12:22       ` Russell King - ARM Linux
2016-04-29  9:32       ` Minfei Huang
2016-04-29  9:32         ` Minfei Huang
2016-04-29  9:30         ` Russell King - ARM Linux
2016-04-29  9:30           ` Russell King - ARM Linux
2016-04-29 10:45           ` Minfei Huang
2016-04-29 10:45             ` Minfei Huang
2016-04-14 20:00 ` [PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t Russell King
2016-04-14 20:00   ` Russell King
2016-04-18  5:38   ` Baoquan He
2016-04-18  5:38     ` Baoquan He
2016-04-18  8:36     ` Russell King - ARM Linux
2016-04-18  8:36       ` Russell King - ARM Linux
2016-04-18 10:32       ` Baoquan He
2016-04-18 10:32         ` Baoquan He
2016-04-18 10:52         ` Russell King - ARM Linux
2016-04-18 10:52           ` Russell King - ARM Linux
2016-04-18 11:28           ` Baoquan He
2016-04-18 11:28             ` Baoquan He
2016-04-28  8:56             ` Russell King - ARM Linux
2016-04-28  8:56               ` Russell King - ARM Linux
2016-04-28  9:59   ` Baoquan He
2016-04-28  9:59     ` Baoquan He

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=20160418053253.GA3602@x1.redhat.com \
    --to=bhe@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=fenghua.yu@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=tony.luck@intel.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.