lkml.org 
[lkml]   [2002]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Faster reboots (and a better way of taking crashdumps?)
On Mon, Apr 08, 2002 at 11:09:26AM -0600, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
>
> > I have been trying look through this in terms of how it compares with
> > alternate projects (bootimg, monte etc). As I mentioned in an earlier
> > mail, crash dump (mcore) relies on bootimg, and I'm trying to decide if
> > there
> > could be advantages in using your kexec stuff.
>
> My target it to submit the kexec stuff to Linus. I seem to be the
> only one really actively working on it at this time. I believe my
> code is the most mature at the moment. The bottom line is the system
> call needs to get into the kernel.
>
> With respect to bootimg there is a strong similarity it how things are
> done. The big difference is that bootimg interface does everything
> per page in asking the kernel where to put things and my kexec call is
> does everything with extents. Which means the kexec data structures
> are usually much smaller, plus I rely on odd things like PAGE_SIZE.

OK.

>
> As for monte I can boot other things than the linux kernel. I'm much
> better at doing the work than publisizing it so my variant isn't quite
> as well known. That plus I can late to the game.
>

I'm not sure if I got this right, but unlike bootimg, monte seems
to prefer going through the early real mode setup code (unless one
specifies skip_setup), and also resets the video mode. At first I
thought some of your querybios stuff achieves a similar effect,
but then is that for linux bios ?

>
> > My main concern of
> > course is with regard to these BIOS dependent/related issues
> > since at the time of a crash dump we may not be in quite a "friendly
> > state". Guess some the linux power mgmt infrastructure or driverfs
> > should help with sane resets etc (I'm not saying its straightforward
> > :)).
> > in the long run. As such how far does your implementation address
> > some of this BIOS/h/w state handling better ?
>
> My code works in SMP. I call the reboot notifier.
> I probably should run through the pci bus and disable bus masters, but
> I don't right now.

The crash dump code with bootimg seems to work on smp
Yes, I noticed the reboot notifier part in your code.
Disabling the busmaster might be required (monte seems to do that)

>
> > BTW, some of your other boot enhancements like being able to find out
> > which memory areas were used or overwritten during bootup sound useful
> > to me, in being able to estimate the footprint of early boot and
> > avoiding
> > using those portions of memory for saving any state (because boot could
> > stomp over them). Its good to be able to do this in a generic way,
> > rather
> > than have the dump code be aware of the ranges for every architecture.
>
> That is why I am a fan of ELF kernel images. There is a lot of
> reasonable resistance to change in that department but it is fairly
> sane.
>
> > > ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.5.7.kexec.diff
> > > ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec-2.5.7.kexec.log
> > > ftp://download.lnxi.com/pub/src/mkelfImage/elfboottools-2.0.tar.gz
> > > type make and see objdir/build/sbin/kexec (work with bzImages)
> >
> > I don't seem to be able to access these urls.
> > The patches I downloaded were from
> > ftp://download.lnxi.com/pub/src/kexec/* (with the same names). Are these
> > the right ones ? (your last note mentioned those, but you are saying
> > that these are the wrong set ... so now I'm a little confused)
>
>
> O.k. My directory structure is just to deep I can't type it straight
> I meant:
> ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec/linux-2.5.7.kexec.diff
> ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec/kexec-2.5.7.kexec.log
>
> And you probably meant:
> ftp://downalod.lnxi.com/pub/src/linux-kernel-patches/kexec.

Yes indeed (except for the spelling of download above :))
Looks like I can't type straight either :)

>
> My other code for cleaning up the boot process is in:
> ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/linux-2.5.7.boot.diff

Ok got it.
Have to get over the tools too and give it a shot.

>
> > Is there one single grand rollup patch with all of the function which I
> > should look through or try out ?
>
> The kexec.diff (instead of the 3 sub patches) is as close as I have
> gotten.
>
> > > The basic kernel interface that is added is:
> > >
> > > struct segment {
> > > void *buffer;
> > > void *dest_addr;
> > > size_t len;
> > > };
> > > int kexec(void *start, int nr_segments, struct segment *segments);
> > >
> >
> > Yes, its a good idea to split up the load stage and actual boot/exec
> > stage. Crash dump needs to have it that way too (the second image
> > preloaded in advance since we don't want to do any i/o at that
> > point).
>
> Interesting. After a lot of discussion this was essentially the
> interface we all agreed upon. Preloading wasn't what I was thinking
> but it works in that sense as well. At least as long as you mlock
> buffers.
>
> The most important piece left with this is to get it accepted into
> the kernel so people can count on a stable system call interface.
>
> Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.091 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site