Quote:
It's worth noting that e4rat predominantly benefits users with traditional hard-disk drives. SSDs probably won't benefit from it since they don't have much access latency. So, it's questionable how much the boot process of an Efika MX will be optimized by e4rat...
It's actually still quite significant because it optimizes the file layout based on the kernel read-ahead behavior. If you imagine the process as follows;
App loads 512 bytes of a file. Kernel reads ahead 16k and buffers it.
App loads 512 bytes of a file which is coincidentally offset into the disk 32k from the first one- kernel cache misses it, so it reads that offset and the kernel reads ahead 16k and buffers it again.
In fact you could take the shorter route, which is to put all the possible accesses within the same 16k, in the right order or close to it, such that every disk access stops being a roundtrip from VFS to cache to SCSI to ATA to Flash controller, and just stop at the cache.
This takes some noticable CPU and IO time, since even an SSD access has some associated latency far and away much larger than an SDRAM access - not nearly as much as a hard disk (where a hard disk is anywhere from 2ms to 200ms, SSD would be anywhere between 20us to 200us depending on the operation) - but still noticable compared to simply looking up a cache entry which is probably in the 100-200ns range (with these values, AT LEAST 200x faster, but we also don't count the userspace->kernel switch time which may again be 100-200ns, maybe a little higher. So let's say somewhere between 50x and 100x?)
Just to summarize in a rather naive way; hard disk latency is measured in tends of milliseconds (1/1000th of a second). SSD latency is measured in the tens of microseconds (1/1000000th of a second). SDRAM latency is measured in the tens of nanoseconds (1/1000000000). Most RISC processors do one instruction per clock, and can fetch from L1 or sometimes L2 cache in one clock (1 nanosecond at 1GHz). For every tip to the next subsystem down the chain, up to switching your SSD back to a standard hard disk, you are increasing the time taken, not including processing, by 1000 just on access time alone. If you include the abstractions, processing time, sorting, buffering, transfer rate, you are still getting a rather significant gain. Even if it's not a million times faster as the theory might suggest, 20x more efficient data access can lead to a 3x faster boot (as per e4rat's bootcharts), which makes your 45 second wait for the login manager into a 12 second one. Imagine what you can do if you have a 5 second boot already...
Probably shave it down to 4.2 seconds, but you get the idea. It's still a significant number of CPU cycles saved if you're counting it in NANO-seconds :)
Login
Register
FAQ
Search