This is totally off-topic but can you tell me whether you came into contact with the top parts of humanity through your work in emergency services too? Is it just the proportions of the parts of humanity that you are likely to come into contact that changes compared to desk jobs?
For example you can read an Ubuntu/Mandriva/Fedora comparison. You can find other benchmarks by scouring the Phoronix articles page. I have a feeling the result is usually a wash with no distro coming out on top on all tests though...
What's most frightening about the 5.1 performance is that nobody knows exactly where it went. If you start asking around, you get plenty of finger-pointing and theories, but few facts. In the May report, I proposed a "5% theory", which states that each little thing we add (Motif, internationalization, drag-and-drop, DSOs, multiple fonts, and so on) costs roughly 5% of the machine. After 15 or 20 of these, most of the performance is gone.
The memo is a great read and if you have the time it's worth a look (it's a shame no one will see this comment really). It's hard to tell whether Ubuntu has a similar situation - without correct measurement it can be terrifyingly hard to tell whether performance has really declined...
There's more to powersaving than just reducing wakeups. On one thinkpad I tried it on wakeups were less than 15 per second but power usage was more than that of Windows. Being able to fully turn off devices and spin down disks will often save more than powertop will (however if you can do all these other things the having a low number of wakeups with a tickless kernel will let you achieve low power usage levels other OSes may struggle to reach). There is a nice paper about the topic of power saving by the renown Linux hacker Matthew Garrett talking about powersaving where much of this is discussed.
With fastboot patches and lots of devices turned off, I can have the Linux kernel take around one second to start the root filesystem on my EeePC. However the more I turn on the longer this becomes. A regular kernel will be closer to five seconds to rootfs.
If you have certain hardware (e.g. arrays of disks that need to spin up when probed) this process may take much longer (minutes...) and there will be little the kernel can do...
Once upon a time most computers had large portions of their OS in ROM. This was fast to access and routinely gave sub second boots. However these days economic pressures coupled with the need to be able to change things after delivery means that few new (desktop) computers are still able to keep the entire OS in ROM and it needs to be loaded into RAM from disk.
While CPU speeds have doubled every few years, the time to access data from (conventional) disks has not halved at nearly the same rate. In fact, if you look at the time it takes to seek to random data you will find seek times have not fallen dramatically in the past decade (they seem to have remained between 4-10ms even as disks have become bigger). This has led to IO becoming a dominant factor in regular computer usage.
As the demand for OSes to do more (GUI, networking, ability to accommodate hotplugging, more devices) increases the size of the OS will slowly rise. Quite often support for large classes of older devices cannot be dropped (otherwise they will stop working) so the need to probe for them lives on. Prettier (and bigger as screen resolutions slowly increase) graphics come with a bigger footprint. Ultimately all this data has to live somewhere but can only be loaded so fast.
Solid state disks will help a bit (especially where data would otherwise be fragmented) but fixed, unchanging installations like TVs will have a massive edge over general purposes computers in boot speed for the foreseeable future.
On another note I remember having to load programs from cassette tape. This could take up to 20 minutes (and there was no guarantee the process would work). By comparison programs on modern machines seem to load at lightening speed. I also remember at the same time loading programs from cartridges. This seemed to take no more than 3 seconds in the worst case. By comparison today's programs seem to plod slothfully into place. Things are simultaneously worse and better!
I'm sorry to hear that suspend to RAM didn't work for you. I think MS did well to get it working well on as many computers as they have done and this is one of those areas where Linux has to work hard to even achieve parity.
Having said that, do you know what kernel you are running? Every release of the linux kernel more fixes go in that enable more machines to work (my own suspend problem was fixed in 2.6.26). If you are using a year old kernel then the tedious advice of "test the latest live CD" (which should have a recent kernel and does not need to be installed to do this test) may yield a different result. With 2.6.27 hopefully things are reaching the point where it should be more likely than not to work...
One thing to note though is that if you are using binary only drivers all bets are off. Those can take huge amounts of tweaking to get going with suspend to RAM and there's no guarantee of success even after hours of trying. If it turns out your problem is binary only driver related it's probably better to give up on suspend to RAM...
Hmm. That's a real problem alright (but probably only noticeable in longer running but partially idle workloads). There are patches floating around that might help to solve in the form of Rik van Riel's split LRU patches. Note tat patch is not yet in mainstream...
..shows a massive improvement. When data you are fetching is scattered over the "disk", the lack of having to wait for the drive to seek to the data before reading it is huge. Sequential throughput of a read on an EeePC SSD is lower (perhaps only 25Mbytes/s?) than that of a regular laptop disk (the speed that both EeePC internal drives get configured to is UDMA 66) but it's hard to arrange for all workloads to be sequentially arranged on disk without perpetually defragging and having only a single reading process at any one time. On parallel read with no writes at all (e.g. early startup) workloads there's often a noticeable win.
The memory manager should be able to cope without swap - there's even a kernel compilation option to not have support for swap at all...
I'm using an EeePC without swap and (thankfully) it doesn't suddenly burst into OOM errors at the drop of a hat so I'm curious about your final paragraph. Are you thinking of overcommit related issues? Could you link to a reference about the poor Linux MM behaviour when running without swap (note this is different to using memory for cache)?
Here's the thing - unless your main nonvolatile media is as fast and smaller than your RAM swap is still useful. What can happen is that pieces of RAM that are very rarely used (e.g. a program that starts up does something then goes to sleep indefinitely) gets swapped out (which initially seems bad because you're going to pay a large price if you ever have to swap it back in). However that RAM is now free for other uses like caching your disk. So disk access to data you've already read which may involve seeking on rotating media and a lot of waiting now become as fast as your RAM. If you have no swap this tradeoff can never be made and the RAM is effectively never reused.
Perhaps I should have said that I've been using some (all?) of the fastboot patches already. I compile kernels from linux-tip which I believe includes fastboot...
My main use case for USB booting is for distro installing where I wouldn't care about the startup speed. The second case was booting from an SD card on my EeePC (where the SD card reader is connected to the USB bus). I guess diskless workstations also fall into this category but you'll have other speed bottlenecks to worry about. Not common cases...
So the answer to your first question is: soon you will be able to set the final video mode in the kernel. As for your second question, doing it in X is not the best solution (as doing it in the kernel means less flickering when X starts, the ability to support graphical kernel panics and nicer virtual terminal switching).
With regard to initrd, I assume having support for it configured into the kernel doesn't slow down the boot. Rather it's the actual use of it that does right?
I'll be interested to see just how close to 1 second for the kernel this system gets with devices enabled (as mentioned its currently at 5). Just for reference here's a big snippet of its dmesg:
...and more about battery life. Less things waking up (or arranging to wake up at the same time) means your computer sleeps for longer and the longer it sleeps deeply the less power it uses.
Not quite sure what happened in my previous post but here's the link to the Interesting but how useful, really? thread (Yes! No! I have a Mac! etc) from the Mandriva story.
Um now letsee er how to make up for the snafu... Here's a link to Moblin project download page that is going to integrate some of this work that the Intel engineers like the now legendary Auke Kok have been working on.
I've administrated network authenticated openSUSE machines and they definitely benefited from booting faster (compared to older versions of openSUSE) - after all the sooner the kernel finishes the sooner you can start waiting for that DHCP lease...The key is that the moment someone says they want to run NIS/LDAP/NFS you just say "start everything that doesn't depend on the network while you wait for the network to come up". In your case NIS/NFS/autofs/xdm DO need the network so they have to wait until that DHCP lease is acquired. No functionality need be lost but the dependencies/order of certain events need to be maintained (this is what tools like Upstart are about).
Parallel boot is the wrong thing; it ends up meaning that you're not really doing the critical path in sequential order; but let the system get distracted from that.
Asynchronous boot (where you let the critical path go sequential, and non-critical pieces asynchronous) is the right answer; the article has a graph about this. And Asynchronous boot you can do just fine with SysVinit.... no magic about that.
Ultimately I doubt people are advocating all of this work for your typical network workstation. For starters such systems don't tend to be using solid state disks with unattended login...
In an attempt to head off the inevitable here's a link straight to the existing Interesting but how useful, really? thread (Yes! No! I have a Mac! I use suspend! I use hibernate! Suspend is broken for me! Hibernate is broken for me! Hibernate takes too long with 500Mbytes! Why do Linux people always say change your habits? Etc.)
What I really want to know is what can be done about usb-storage and pciehp (PCI Express hotplug). I have an EeePC 900 using a kernel with Arjan's fastboot patches and with USB entirely disabled and pciehp turned off the kernel mounts the root filesystem in just over one second. With USB on and pciehp in use it's over 5 seconds....
...and wants to do something malicious then I'd worry about something other than not having to guess a correct username. Unless you're using full disk and virtual memory encryption why wouldn't they just boot off a CD/USB key (or possibly take your disk out and put it in another machine)?
While servers still seem to take hours to get past their BIOSes, modern laptops often have options for skipping the POST and generally taking shortcuts enumerating devices. The EeePC has a "BootBooster" option where it caches BIOSes results to solid state disk so the BIOS finishes in less than a second (rather than 4 or 5). It is so fast it can be a pain when you actually DO want to change a BIOS option!
Slashdot Mirror
This is totally off-topic but can you tell me whether you came into contact with the top parts of humanity through your work in emergency services too? Is it just the proportions of the parts of humanity that you are likely to come into contact that changes compared to desk jobs?
Your comment made me smile.
For example you can read an Ubuntu/Mandriva/Fedora comparison. You can find other benchmarks by scouring the Phoronix articles page. I have a feeling the result is usually a wash with no distro coming out on top on all tests though...
In an internal memo SGI's Tom Davis criticised some of what had come to pass in Irix 5.1. Within the memo he propsed that it was effectively a death by a thousand cuts (well 20 cuts I guess):
The memo is a great read and if you have the time it's worth a look (it's a shame no one will see this comment really). It's hard to tell whether Ubuntu has a similar situation - without correct measurement it can be terrifyingly hard to tell whether performance has really declined...
There's more to powersaving than just reducing wakeups. On one thinkpad I tried it on wakeups were less than 15 per second but power usage was more than that of Windows. Being able to fully turn off devices and spin down disks will often save more than powertop will (however if you can do all these other things the having a low number of wakeups with a tickless kernel will let you achieve low power usage levels other OSes may struggle to reach). There is a nice paper about the topic of power saving by the renown Linux hacker Matthew Garrett talking about powersaving where much of this is discussed.
With fastboot patches and lots of devices turned off, I can have the Linux kernel take around one second to start the root filesystem on my EeePC. However the more I turn on the longer this becomes. A regular kernel will be closer to five seconds to rootfs.
If you have certain hardware (e.g. arrays of disks that need to spin up when probed) this process may take much longer (minutes...) and there will be little the kernel can do...
Once upon a time most computers had large portions of their OS in ROM. This was fast to access and routinely gave sub second boots. However these days economic pressures coupled with the need to be able to change things after delivery means that few new (desktop) computers are still able to keep the entire OS in ROM and it needs to be loaded into RAM from disk.
While CPU speeds have doubled every few years, the time to access data from (conventional) disks has not halved at nearly the same rate. In fact, if you look at the time it takes to seek to random data you will find seek times have not fallen dramatically in the past decade (they seem to have remained between 4-10ms even as disks have become bigger). This has led to IO becoming a dominant factor in regular computer usage.
As the demand for OSes to do more (GUI, networking, ability to accommodate hotplugging, more devices) increases the size of the OS will slowly rise. Quite often support for large classes of older devices cannot be dropped (otherwise they will stop working) so the need to probe for them lives on. Prettier (and bigger as screen resolutions slowly increase) graphics come with a bigger footprint. Ultimately all this data has to live somewhere but can only be loaded so fast.
Solid state disks will help a bit (especially where data would otherwise be fragmented) but fixed, unchanging installations like TVs will have a massive edge over general purposes computers in boot speed for the foreseeable future.
On another note I remember having to load programs from cassette tape. This could take up to 20 minutes (and there was no guarantee the process would work). By comparison programs on modern machines seem to load at lightening speed. I also remember at the same time loading programs from cartridges. This seemed to take no more than 3 seconds in the worst case. By comparison today's programs seem to plod slothfully into place. Things are simultaneously worse and better!
I'm sorry to hear that suspend to RAM didn't work for you. I think MS did well to get it working well on as many computers as they have done and this is one of those areas where Linux has to work hard to even achieve parity.
Having said that, do you know what kernel you are running? Every release of the linux kernel more fixes go in that enable more machines to work (my own suspend problem was fixed in 2.6.26). If you are using a year old kernel then the tedious advice of "test the latest live CD" (which should have a recent kernel and does not need to be installed to do this test) may yield a different result. With 2.6.27 hopefully things are reaching the point where it should be more likely than not to work...
One thing to note though is that if you are using binary only drivers all bets are off. Those can take huge amounts of tweaking to get going with suspend to RAM and there's no guarantee of success even after hours of trying. If it turns out your problem is binary only driver related it's probably better to give up on suspend to RAM...
Hmm. That's a real problem alright (but probably only noticeable in longer running but partially idle workloads). There are patches floating around that might help to solve in the form of Rik van Riel's split LRU patches. Note tat patch is not yet in mainstream...
..shows a massive improvement. When data you are fetching is scattered over the "disk", the lack of having to wait for the drive to seek to the data before reading it is huge. Sequential throughput of a read on an EeePC SSD is lower (perhaps only 25Mbytes/s?) than that of a regular laptop disk (the speed that both EeePC internal drives get configured to is UDMA 66) but it's hard to arrange for all workloads to be sequentially arranged on disk without perpetually defragging and having only a single reading process at any one time. On parallel read with no writes at all (e.g. early startup) workloads there's often a noticeable win.
The memory manager should be able to cope without swap - there's even a kernel compilation option to not have support for swap at all...
I'm using an EeePC without swap and (thankfully) it doesn't suddenly burst into OOM errors at the drop of a hat so I'm curious about your final paragraph. Are you thinking of overcommit related issues? Could you link to a reference about the poor Linux MM behaviour when running without swap (note this is different to using memory for cache)?
Here's the thing - unless your main nonvolatile media is as fast and smaller than your RAM swap is still useful. What can happen is that pieces of RAM that are very rarely used (e.g. a program that starts up does something then goes to sleep indefinitely) gets swapped out (which initially seems bad because you're going to pay a large price if you ever have to swap it back in). However that RAM is now free for other uses like caching your disk. So disk access to data you've already read which may involve seeking on rotating media and a lot of waiting now become as fast as your RAM. If you have no swap this tradeoff can never be made and the RAM is effectively never reused.
Looking around this Kenreltrap article contains a thread where someone asks is swap necessary? which might provide a better explanation than the one I've given.
Perhaps I should have said that I've been using some (all?) of the fastboot patches already. I compile kernels from linux-tip which I believe includes fastboot...
My main use case for USB booting is for distro installing where I wouldn't care about the startup speed. The second case was booting from an SD card on my EeePC (where the SD card reader is connected to the USB bus). I guess diskless workstations also fall into this category but you'll have other speed bottlenecks to worry about. Not common cases...
Kernel modesetting is kinda here for Intel and ATI graphics cards (in Fedora) but it's still stabilizing.
So the answer to your first question is: soon you will be able to set the final video mode in the kernel. As for your second question, doing it in X is not the best solution (as doing it in the kernel means less flickering when X starts, the ability to support graphical kernel panics and nicer virtual terminal switching).
The USB parallel initialization work sounds fantastic (and thanks for replying on Slashdot - we don't see many big shot devs here)!
As for pciehp, you can't disable then enable the wireless card and expect ath5k not to lose its marbles unless you boot with pciehp_force=1.
With regard to initrd, I assume having support for it configured into the kernel doesn't slow down the boot. Rather it's the actual use of it that does right?
I'll be interested to see just how close to 1 second for the kernel this system gets with devices enabled (as mentioned its currently at 5). Just for reference here's a big snippet of its dmesg:
[ 0.000999] Memory: 1026236k/1039872k available (2576k kernel code, 12968k re .init : 0xc046e000 - 0xc04a9000 ( 236 kB) .data : 0xc0384150 - 0xc046bdd0 ( 927 kB) .text : 0xc0100000 - 0xc0384150 (2576 kB) ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
served, 927k data, 236k init, 130568k highmem)
[ 0.000999] virtual kernel memory layout:
[ 0.000999] fixmap : 0xfffac000 - 0xfffff000 ( 332 kB)
[ 0.000999] pkmap : 0xff800000 - 0xffc00000 (4096 kB)
[ 0.000999] vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB)
[ 0.000999] lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB)
[ 0.000999]
[ 0.000999]
[ 0.000999]
[ 0.000999] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[ 0.000999] SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.001016] Calibrating delay loop (skipped), value calculated using timer frequency.. 1800.21 BogoMIPS (lpj=900106)
[ 0.001043] Security Framework initialized
[ 0.001063] Mount-cache hash table entries: 512
[ 0.001318] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.001324] CPU: L2 cache: 512K
[ 0.001330] Intel machine check architecture supported.
[ 0.001338] Intel machine check reporting enabled on CPU#0.
[ 0.001350] CPU: Intel(R) Celeron(R) M processor 900MHz stepping 08
[ 0.001361] Checking 'hlt' instruction... OK.
[ 0.005636] Freeing SMP alternatives: 0k freed
[ 0.005640] ACPI: Core revision 20080609
[ 0.021353]
[ 0.031995] net_namespace: 288 bytes
[ 0.031995] NET: Registered protocol family 16
[ 0.031995] No dock devices found.
[ 0.031995] ACPI: bus type pci registered
[ 0.031995] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.031995] PCI: Not using MMCONFIG.
[ 0.032002] PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5
[ 0.032006] PCI: Using configuration type 1 for base access
[ 0.035375] ACPI: EC: Look up EC in DSDT
[ 0.047947] ACPI: Interpreter enabled
[ 0.047956] ACPI: (supports S0 S1 S3 S5)
[ 0.047980] ACPI: Using IOAPIC for interrupt routing
[ 0.048105] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.051277] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources
[ 0.051282] PCI: Using MMCONFIG for extended config space
[ 0.062285] ACPI: EC: GPE = 0x18, I/O: command/status = 0x66, data = 0x62
[ 0.062291] ACPI: EC: driver started in poll mode
[ 0.062512] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.062669] PCI: 0000:00:02.0 reg 10 32bit mmio: [f7f7fffff7f00000, f7070580f70704e8]
[ 0.062678] PCI: 0000:00:02.0 reg 14 io port: [ec070000ec00, f707059cf70704e8]
[ 0.062686] PCI: 0000:00:02.0 reg 18 32bit mmio: [dfffffffd0000000, f70705b8f70704e8]
[ 0.062694] PCI: 0000:00:02.0 reg 1c 32bit mmio: [f7effffff7ec0000, f70705d4f70704e8]
[ 0.062731] PCI: 0000:00:02.1 reg 10 32bit mmio: [f7fffffff7f80000, f7070980f70708e8]
[ 0.062825] PCI: 0000:00:1b.0 reg 10 64bit mmio: [f7ebbffff7eb8000, f7070ce8f7005948]
[ 0.062870] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.062877] pci 0000:00:1
...and more about battery life. Less things waking up (or arranging to wake up at the same time) means your computer sleeps for longer and the longer it sleeps deeply the less power it uses.
When you're booting off a USB device you often seem to need scripts in initrd to keep retrying to mount the rootfs until it appears...
Not quite sure what happened in my previous post but here's the link to the Interesting but how useful, really? thread (Yes! No! I have a Mac! etc) from the Mandriva story.
Um now letsee er how to make up for the snafu... Here's a link to Moblin project download page that is going to integrate some of this work that the Intel engineers like the now legendary Auke Kok have been working on.
I've administrated network authenticated openSUSE machines and they definitely benefited from booting faster (compared to older versions of openSUSE) - after all the sooner the kernel finishes the sooner you can start waiting for that DHCP lease...The key is that the moment someone says they want to run NIS/LDAP/NFS you just say "start everything that doesn't depend on the network while you wait for the network to come up". In your case NIS/NFS/autofs/xdm DO need the network so they have to wait until that DHCP lease is acquired. No functionality need be lost but the dependencies/order of certain events need to be maintained (this is what tools like Upstart are about).
Strangely enough in one of the article's comments you'll find that Arjan isn't advocating a parallel boot:
Ultimately I doubt people are advocating all of this work for your typical network workstation. For starters such systems don't tend to be using solid state disks with unattended login...
This is effectively related to an earlier Slashdot story about the changes Mandriva are making to speed up boot on their distro
In an attempt to head off the inevitable here's a link straight to the existing
Interesting but how useful, really? thread (Yes! No! I have a Mac! I use suspend! I use hibernate! Suspend is broken for me! Hibernate is broken for me! Hibernate takes too long with 500Mbytes! Why do Linux people always say change your habits? Etc.)
What I really want to know is what can be done about usb-storage and pciehp (PCI Express hotplug). I have an EeePC 900 using a kernel with Arjan's fastboot patches and with USB entirely disabled and pciehp turned off the kernel mounts the root filesystem in just over one second. With USB on and pciehp in use it's over 5 seconds....
Finally here's a link to Arjan's slides from the presentation about 5 second boot in PowerPoint format and a YouTube video of the 5 second boot on an EeePC 901.
Thanks for following up - I'd been flipping through algorithms books looking for this : )
Here's a poweropint presentation about this work. If you're an LWN subscriber you can you read an article and comments about the 5 second boot presentation at the Linux Plumbers Conference (it will become viewable by all on from the 2nd October 2008). Finally you might be able to test drive some of this work if you are willing to sacrifice a USB key and destroy your existing EeePC install by because Moblin may include this work.
...and wants to do something malicious then I'd worry about something other than not having to guess a correct username. Unless you're using full disk and virtual memory encryption why wouldn't they just boot off a CD/USB key (or possibly take your disk out and put it in another machine)?
While servers still seem to take hours to get past their BIOSes, modern laptops often have options for skipping the POST and generally taking shortcuts enumerating devices. The EeePC has a "BootBooster" option where it caches BIOSes results to solid state disk so the BIOS finishes in less than a second (rather than 4 or 5). It is so fast it can be a pain when you actually DO want to change a BIOS option!