Andrew Morton wrote:
The above data is enough for performing a crude preload:
a) Boot the machine
b) Boost the disk queue size, set the VFS readahead to zero, open
/dev/hda1 and all the regular files, hose reads at the disk via
fadvise(). Restore VFS readahead and queue size, continue with boot.
opening all these files will require synchronous reads of their
directories and inodes, so you might need to split b) into first opening
and reading /dev/hda1, then opening and reading the regular files.
And I suspect that the whole thing will be of marginal benefit. Although
things might be better now that files are laid out with the Orlov allocator
(make sure that the distro was installed with a 2.6 kernel! The file
layout will be quite different if the installer used a 2.4 ext3).
Of course the next step is to rewrite files so that they are more
favourably laid out on disk. Tricky. Or dump all pagecache to some temp
file in a nice linear slurp and preload that, copying it all to the
appropriate per-inode pagecaches and taking care of files which have been
modified. Trickier ;)
another possibility: use a device mapper module under /dev/hda1 that
records I/O patterns, then relocates blocks to fit that pattern, so that
the normal boot sequence ends up issuing sequential disk writes.
parallelized initscripts will probably defeat this, though.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |