| |||||||||||||
sreadaheadsreadaheadPosted Aug 30, 2010 16:01 UTC (Mon) by giraffedata (subscriber, #1954)In reply to: sreadahead by arjan Parent article: LinuxCon: A tale of two bootcharts
On a solid-state block device, where order doesn't matter, what is the point of sreadahead? The only advantage I know to reading stuff into cache ahead of time is that you can do it in optimal order. With disk drives, I don't think user space should be ordering the reads -- that expertise belongs in the block layer and below. All you have to do is pile all the read requests into the block layer and it will order them properly (of course, you don't have to get everything in the queue at once -- eliminating 99% of the seek time is fine). And though I don't know what the state of implementation is, in theory you shouldn't be piling anything explicitly into the block layer either; you should just be advising the block layer of your plans to read that stuff later (madvise).
(Log in to post comments)
sreadahead Posted Aug 30, 2010 20:07 UTC (Mon) by Jonno (subscriber, #49613) [Link] 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.
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.
|
|||||||||||||