All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Marti Raudsepp <marti@juffo.org>
Cc: systemd-devel <systemd-devel@lists.freedesktop.org>,
	kexec list <kexec@lists.infradead.org>,
	Lennart Poettering <lennart@poettering.net>
Subject: Re: Doing kexec reboot right in systemd
Date: Fri, 23 Mar 2012 07:36:46 +0900	[thread overview]
Message-ID: <20120322223646.GC26794@verge.net.au> (raw)
In-Reply-To: <CABRT9RAB--szWwmYO9_JyjXRP-9YYgkG-TsAg8jS=birUF2e=w@mail.gmail.com>

On Thu, Mar 22, 2012 at 09:14:56PM +0200, Marti Raudsepp wrote:
> Hi list,

Hi Marti,

> I was recently pondering how systemd could use kexec "properly", in a
> reasonably general way, to make reboots faster. I exchanged an email
> with Poettering on the systemd list and he suggested me to ask here.
> 
> My current proposal:
> 1. Include a template 'kexec-load.service' with kexec-tools, which
> distros/users could customize to load the right kernel and initrd via
> /sbin/kexec
> 
> 2. If the user does 'systemctl enable kexec-load.service', then this
> service would trigger before every reboot. Loading the kernel any
> earlier would waste memory (5+14 MB on Ubuntu Server). Also a common
> reason for rebooting is to boot into a newly-installed kernel. Loading
> it any earlier would boot you into an older kernel.
> 
> 3. During a reboot, after systemd has finished shutting down, it
> detects via /sys/kernel/kexec_loaded whether the kexec kernel is
> loaded. If 1, it performs a 'kexec -e'. If not, it does a normal
> reboot.
> 
> ----
> 
> Lennart commented on #2 that kexec might have problems finding
> contiguous memory to load the kernel into, this late in the lifecycle.
> Do you think this is a deal-breaker for such a feature? If it's rare
> enough, then it might not be a problem -- we can always fall back to a
> normal reboot.

In general kexec doesn't store the kernel in contiguous memory at load-time.
Rather, when kexec -e is called the kernel is copped from (most likely)
discontiguous pages) into its destination location.

> I'm also assuming that "kexec --load" will fail atomically -- that it
> won't try to boot a half-loaded kernel, or boot a kernel whose initrd
> failed to load.

Yes, that is correct.

However, I speculate that there is a greater chance of the boot of a
kexeced kernel failing than the same kernel booting by more conventional
means on the same hardware. Primarily because there are most likely
shutdown/boot paths, especially in drivers, that have not been well
exercised.

So while it may work well on some hardware, perhaps even most hardware, I
suspect there are cases where it will fail.  I guess that is where
systemctl enable/disable kexec-load.service comes into play.

> Also, #3 doesn't yet work that way in systemd (currently it detects
> before shutdown) and Poettering hasn't agreed yet.
> 
> Does this proposal seem sane to kexec folks? Did I miss anything?

If it is desirable to use kexec as a reboot mechanism then
from a kexec point of view I think your proposal makes sense.

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

  reply	other threads:[~2012-03-22 22:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-22 19:14 Doing kexec reboot right in systemd Marti Raudsepp
2012-03-22 22:36 ` Simon Horman [this message]
2012-03-26 18:07   ` Lennart Poettering
2012-03-26 18:25     ` Marti Raudsepp
2012-03-27 10:01       ` Lennart Poettering
2012-03-27 23:19         ` Simon Horman
2012-03-23  9:35 ` Bouchard Louis
2012-03-23 18:45   ` Marti Raudsepp

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=20120322223646.GC26794@verge.net.au \
    --to=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=lennart@poettering.net \
    --cc=marti@juffo.org \
    --cc=systemd-devel@lists.freedesktop.org \
    /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.