| |||||||||||||
Kernel Summit: kexec and fast booting
Additionally, the consumer electronics people are interested in "execute in place" (XIP) capability. On many small devices, the kernel (and applications too) is located in flash memory which is directly addressable by the processor. Rather than copy the kernel from flash to RAM, why not run it directly from its place in flash, avoid the copy, and preserve RAM space? The downside is that flash tends to be slower, so there will be a performance penalty. There is talk of trying to copy just the "hotspots" in the kernel code to RAM; this approach looks like a recipe for complexity and trouble. The kexec patch turns out to have another use, which was revisited in the next session: it can be set up to preserve part of kernel memory over the reboot. If things are carefully done, it can thus be used to implement a sort of crash dump capability. (Log in to post comments)
Kernel Summit: kexec and fast booting Posted Jul 21, 2004 22:13 UTC (Wed) by hensema (guest, #980) [Link] Note that the random seeks on disk can be avoided by a technique used by Windows XP: that OS 'remembers' what sectors of the disk were accessed during boot, and places them close to each other on disk. This is a kind of optimized disk defragmentation. There is a lot of performance to be gained with this technique, I think.Also, this is desperately needed. Booting Linux is slow. Very slow. On a server this is no problem, but it's not acceptable on a desktop which is switched off every night.
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 0:06 UTC (Thu) by smoogen (subscriber, #97) [Link] Windows only locates some minimal items to the front of the disk. The rest are still located all over the disk. The save most of their time by delaying most items until a user has logged in. So you get the window up front asap and the apps you need later. They also have an 'integrated' windowing system and kernel. Putting X into the kernel would speed up boot time tons...of course it would lead to a lot of problems.
Can X be started earlier? Posted Jul 22, 2004 14:59 UTC (Thu) by southey (subscriber, #9466) [Link] It would seem to me that you should be able to get X running before Linux is completely booted for users that want a GUI. Now with the XFree86 fork, perhaps it will be possible to initialize the kernel and X with perhaps the user's GUI of choice. It also seems that it should take advantage of multiple cpus and hyperthreading when available.
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 19:15 UTC (Thu) by iabervon (subscriber, #722) [Link] If the kernel didn't block booting while initializing devices, it could start init as soon as the device with the root filesystem was found, and X could start as soon as the video device was detected. It wouldn't actually help to put X in the kernel (aside, I guess, from having it loaded efficiently by the bootloader before other things are using the disk); the real gains would come from not waiting for anything unnecessary. For that matter, it doesn't matter where X is if xdm isn't started until after alsa, exim, inetd, lpd, sshd, atd, and cron.
Kernel Summit: kexec and fast booting Posted Jul 29, 2004 15:48 UTC (Thu) by astor (guest, #7383) [Link] It should be possible to do a simple version of this - just remember all the programs that were executed during startup, and put them in a cramfs image which is used as a cachefs/overlaidfs over the original file system during booting. It should be possible to read the cramfs in a few seconds.
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 3:02 UTC (Thu) by stock (guest, #5849) [Link] http://wiki.linuxquestions.org/wiki/ScriptingSLEEP COMMANDS sleep command usleep command Today's typical developer main PC at home is a P4 or AMD screaming fast iron. These new programmers actually miss the resource limiting constraints of a Atari St, Amiga 3000, Commodore 64 or even a 8088 Intel PC with only 640 kbyte RAM. For sake! Even Bill Gates once said the 640 kb RAM limit would never be exceeded. Nowadays, besides RAM abuse, CPU cycles are really abused in god forbidden ways and methods. For e.g. pcmcia and hotplug to work, its common practice that inside a startup script the kudzu program is called several times in a row. Next if one counts inside /etc/rc.d/init.d directory the number of "sleep 1" calls, one finally understands why that P4 3.0 GHz hotrod iron is still slower at booting up as my old pentium P75 with RedHat 4.2 : [root@tinker init.d]# grep sleep * | wc -l 31 [root@tinker init.d]# So booting might at least take 30 seconds extra due to sleep commands. One might check /etc/init.d/functions where the sleep command is used inside a loop! Why not use the usleep command? This command uses a microsecond as its time unit instead of a whole second. My solution would be to replace all sleep shell scripting commands with usleep and put 2 or 3 zeros behind the number of seconds . so one would replace : sleep 1 ==> usleep 1000 1 second ===> 1 msec Your Linux machine and its scripts might boot/run a 1000 times faster after this. Robert
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 12:34 UTC (Thu) by Rakshasa (guest, #14732) [Link] I wonder... how many of those "slow" sleep commands are in the restart sections?
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 23:58 UTC (Thu) by melauer (guest, #2438) [Link] > I wonder... how many of those "slow" sleep commands are in the restart> sections? Or, for that matter, in services which you don't use. [me@localhost init.d]$ grep sleep * | wc -l 22 [me@localhost init.d]$ grep sleep * alsa: sleep 1 dm: sleep 5 functions: usleep 100000 functions: if checkpid $pid && sleep 1 && functions: checkpid $pid && sleep 3 && functions: usleep 100000 halt:sleep 5 halt: sleep 5 halt: sleep 2 halt: sleep 5 halt: sleep 120 lm_sensors: sensors -s && sleep 2 firewall: sleep 1 mtink: sleep 2 netfs: sleep 5 netfs: sleep 2 netfs: sleep 5 netfs: sleep 2 netfs: sleep 5 pcmcia: sleep 2 single:sleep 5 sshd: sleep 3 I'm pretty sure that sleep commands in "halt" don't matter in booting, and I don't use "netfs" (the other top offender) or many of these other services.
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 4:32 UTC (Thu) by flewellyn (subscriber, #5047) [Link] The "known devices list" could be a compile-time option, in which the system is probed for device info, which is saved in the kernel. Then, when rebooted, the new kernel would already know what was there, and thus be able to avoid probing.Of course, this would not work with hotplug devices, and certainly not when compiling for a different system. So it would have to be an option.
Kernel Summit: kexec and fast booting Posted Jul 22, 2004 13:29 UTC (Thu) by PaulDickson (subscriber, #478) [Link] Every time a system shuts down, the used devices can be recorded. Withenough reboots, a common list of the system's devices will become known. This list can then be saved on the system's init ram disk so upon further
|
|||||||||||||