On Fri, May 04 2001, Richard Gooch wrote:
> The idea I had (motivated by the desire to eliminate random disc
> seeks, which is the limiting factor in how fast my boxes boot) was:
>
> - init(8) issues an ioctl(2) on the root FS block device which turns
> on recording of block reads (it records block numbers)
>
> - at the end of the bootup process, init(8) issues another ioctl(2) to
> grab the buffered block numbers, and turn off recording
>
> - init(8) then sorts this list in ascending order and saves the result
> in a file
>
> - next boot, init(8) checks the file, and if it exists, opens the root
> FS block device and reads in each block listed in the file. The
> effect is to warm the buffer cache extremely quickly. The head will
> move in one direction, grabbing data as it flys by. I expect this
> will take around 1 second
>
> - init(8) now continues the boot process (starting the magic ioctl(2)
> again so as to get a fresh list of blocks, in case something has
> changed)
>
> - booting is now super fast, thanks to no disc activity.
I did 95% of what you need sometime last year, to do I/O scheduler
profiling (blocks requested, merge stats, request sent to disk). It was
a pretty gross hack, requiring a pretty big ring buffer of kernel memory
to be able to log at a sufficiently fast rate (you'd be amazed how much
output a single dbench 48 run produces :-). A user space app would read
data from a simple char device, save for later inspection.
A better approach would be to map the ring buffer from the user app, but
it was just a quick fix.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
