sreadahead
sreadahead
Posted Aug 30, 2010 21:59 UTC (Mon) by giraffedata (guest, #1954)In reply to: sreadahead by Jonno
Parent article: LinuxCon: A tale of two bootcharts
The main advantage is to never have to do iowait but always have the data you need at hand. Eg doing 10 seconds of disk reads and 15 seconds of CPU time in 15 seconds rather than in 25 seconds.
OK, I forgot about that. So I take it sreadahead runs in parallel with other boot processes?
But just based on what I've seen and heard my disk drive do during painfully slow boots, I'll bet the CPU time is dwarfed by the seek time, so overlapping CPU and disk time wouldn't buy a whole lot.
Posted Sep 2, 2010 3:18 UTC (Thu)
by blitzkrieg3 (guest, #57873)
[Link] (1 responses)
That's the whole point. The HD is doing a lot of seeking when it could just be moving the head down the platter across all of the tracks linearly, which means zero seek time.
Also look at the charts, even if you discount the HD seeking, it buys about 7 seconds. Otherwise these seconds would be spread about the boot while a process was blocking instead of actually running.
Posted Sep 2, 2010 6:09 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
That's the whole point of what? It wasn't the point of the article or any previous comment, since they talked about SSDs (no seek time) and about CPU overlapping disk time. (Simply overlapping CPU and disk time, on mechanical disk systems I know would be barely noticeable, because the disk time is so great compared to the CPU time).
On the SSD-based system, though, the overlap is significant because the disk time is so much shorter. If overlapping buys you 7 seconds toward a 10 second boot, the CPU time and disk time must be of the same order.
sreadahead
sreadahead
That's the whole point. The HD is doing a lot of seeking when it could just be moving the head down the platter across all of the tracks linearly, which means zero seek time.