From: Andy Pfiffer <andyp@osdl.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: suparna@in.ibm.com, "Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Faster reboots (and a better way of taking crashdumps?)
Date: 10 Apr 2002 10:58:42 -0700 [thread overview]
Message-ID: <1018461522.4453.212.camel@andyp> (raw)
In-Reply-To: <m1y9fvlfyb.fsf@frodo.biederman.org>
On Wed, 2002-04-10 at 08:40, Eric W. Biederman wrote:
> Unless I missed something the Linux kernel won't work on smp though.
> It is a matter of resetting the state of the apics, and ensuring you
> are running on the first processor. I don't believe bootimg did/does that.
>
The copy of bootimg that I have makes no effort to offline CPU's or
reset the APICs. If there is a newer version, I could not find it.
I have tried 3 different solutions for for Linux-reloading-linux
(bootimg, two-kernel monte, and kexec), and none of them fully support
the kinds of enterprise-class systems we (OSDL) care about:
1. multiprocessor x86 (p3, p4, +xeons) with APICs
2. >4GB memory
3. CPU hotplug
4. device hotplug
5. >= 2.5.x kernel
In fact, I have yet to find any variation of linux-loading-linux that
works at all on the 2-way P4-Xeon under my desk or the 8-way P3-Xeon in
the lab. The only system I have ever seen Two Kernel Monte work on here
is a Celeron-based machine in a nearby cube.
Why do we care about this? Rebooting these kinds of sytsems can take
several minutes, and in my sample of the systems in the lab, ~80% of the
reboot time is spent slogging through the platform's firmware, ~20% of
the time is spent between LILO and login:. 80% of several minutes is
often greater than the allowable annual downtime for some enterprise
systems.
What about LinxuBIOS? While an attractive solution for many, it is a
long, uphill battle to add support for chipset after chipset, and
motherboard after motherboard.
The >4GB of memory problem is an interesting quirk -- if the
linux-loading-linux implementation assumes that it can perform the final
copy in 32-bit protected mode *without* paging enabled, it won't
reliably work on >4GB systems.
> In general yes. There are some interesting side effects though.
> Going through the pci bus and shutting off bus masters is a good
> first approximation of what needs to happen.
>
The new device model from Pat (mochel@osdl.org) is probably the best way
to go here; you'll be able to walk the driver tree and reliably turn off
devices.
For the CPU side of things, the CPU hotplug work looks promising as
well.
Andy
next prev parent reply other threads:[~2002-04-10 17:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-07 1:32 Faster reboots (and a better way of taking crashdumps?) Martin J. Bligh
2002-04-07 2:50 ` Eric W. Biederman
2002-04-07 4:00 ` Martin J. Bligh
2002-04-07 4:12 ` Eric W. Biederman
2002-04-08 14:31 ` Suparna Bhattacharya
2002-04-08 17:09 ` Eric W. Biederman
2002-04-09 15:26 ` Suparna Bhattacharya
2002-04-10 15:40 ` Eric W. Biederman
2002-04-10 17:58 ` Andy Pfiffer [this message]
2002-04-11 14:15 ` Suparna Bhattacharya
2002-04-11 15:08 ` Eric W. Biederman
2002-04-16 10:02 ` Pavel Machek
2002-04-16 22:59 ` Alan Cox
2002-04-11 13:56 ` Suparna Bhattacharya
2002-04-11 15:35 ` Eric W. Biederman
2002-04-12 14:49 ` Suparna Bhattacharya
2002-04-12 17:59 ` Eric W. Biederman
2002-04-15 10:07 ` Suparna Bhattacharya
-- strict thread matches above, loose matches on Subject: below --
2002-04-05 19:13 Martin J. Bligh
2002-04-05 20:47 ` Jeremy Jackson
2002-04-06 1:48 ` Martin J. Bligh
2002-04-06 2:55 ` Jeremy Jackson
2002-04-08 7:20 ` Suparna Bhattacharya
2002-04-11 3:47 ` Jeremy Jackson
2002-04-11 14:28 ` Suparna Bhattacharya
2002-04-06 17:56 ` Alan Cox
2002-04-07 1:35 ` Martin J. Bligh
2002-04-06 23:27 ` Eric W. Biederman
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=1018461522.4453.212.camel@andyp \
--to=andyp@osdl.org \
--cc=Martin.Bligh@us.ibm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox