Konstantin Svist wrote:
Bill Davidsen wrote:
Fedora is currently not targeted to embedded dedicated applications. I
doubt that you will see a practical five second boot on server or
workstation commercial hardware any time soon. By practical here I
mean something that doesn't need to be tuned to each machine and/or
assume anything on the network (DNS or DHCP servers) will respond
instantly.
The way some tests count "boot time" starts with a machine up and
running at the boot manager, ignoring real world stuff like disk
spinup, etc, it tests a portion of the delay from power on to ready to
use.
IIRC, the idea was to initialize hardware in parallel. The only thing
(?) required for this to work is using kernel alone, without initrd.
So my question is, how plausible is running Fedora without initrd? Don't
the majority of users out there have similar hardware, making initrd
unnecessary?
A little hard to initialize hardware in parallel with disk, until you can read
the kernel you aren't going to boot. And until you have a network connection in
many cases you have a boot screen but no useful capabilities.
My thought is that what's needed is a utility which can be run after the classic
boot currently used, which could generate one kernel image to avoid module
loads. Sort of "suspend to disk" combined with cold boot, where the kernel could
be read into memory in a single disk i/o.
I also note that there is no use made of hardware capacity. So even if I have
two, or four, or sixteen CPUs, things don't get started in parallel, and my
readahead values on block devices (blockdev cmd) don't get bumped to a larger
value even on machines with 4 or more GB of memory.
Example boot output attached.
Even using initrd we could do a lot better.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
