| |||||||||||||
sreadaheadsreadaheadPosted Aug 30, 2010 20:07 UTC (Mon) by Jonno (subscriber, #49613)In reply to: sreadahead by giraffedata Parent article: LinuxCon: A tale of two bootcharts
The only advantage I know to reading stuff into cache ahead of time is that you can do it in optimal order. 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.
(Log in to post comments)
sreadahead Posted Aug 30, 2010 21:59 UTC (Mon) by giraffedata (subscriber, #1954) [Link] 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.
sreadahead Posted Sep 2, 2010 3:18 UTC (Thu) by blitzkrieg3 (subscriber, #57873) [Link]
> 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.
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.
sreadahead Posted Sep 2, 2010 6:09 UTC (Thu) by giraffedata (subscriber, #1954) [Link] 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. 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.
|
|||||||||||||