David Nielsen wrote:
søn, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta:
On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
Well, I looked into the readahead util for boot time, and it seemed to
hurt more than help. But ongoing preload that learns & adjusts to usage
patterns could help I'm sure, if done right
That wont help the critical first impression phase.. before
application usage patterns are established and people are feeling out
the release. And to be more blunt about it.. it won't help first
impression from the reviewers who run a distro just long enough to
figure what they like and don't like about it and want to get their
review in within the first week of a release.
How many people end up relying on the first impression of others to
form their own impressions? Adaptive methods that only help boot
speeds after multiple reboots with extended usage pattern trending
isn't really going to impact the impression people have one damn bit.
And it wont help livecds where state information is lost between reboots.
Would it be possible to pre-seed such an adaptive scheme.. we know what
we call on boot on a out of the box F9 final.
Personally of course, I think the long term ideal solution might end up
looking like my method with the livecd, percolating to normal usage.
I.e. my method does a precooking boot under qemu during livecd compose
to get file access order. Then creates the ext3 fsimage on the livecd
with that sorting order, by just copying the files in order. Then when
booting, preloads a chunk from the beginning of the fs into ram(tmpfs),
in one big long read. Then after boot is done, discards the chunk in
ram. (And the size of the chunk is determined by how much ram the
system has.)
This already has a benefit of minimizing seeks for disk based
installation once this ext3 image is copied to the hard drive, during a
normal livecd installation now.
The key to making this an ideal disk-boot solution, is that you need a
daemon which watches each boot, and resorts the blocks on the ext3fs
such that the earlier they are accessed relative to boot, the closer
they are to the outter rim of the filesystem. And then using the same
devicemapper ram caching trick during disk-boot as during livecd-boot.
Note, the above method doesn't minimize seeks like sorting does, it
removes them, as a huge chunk is read into ram with just a singe seek.
I suspect something similar had been discussed for disk-boot before, but
probably has been shelved because of the trouble of keeping the fs
sorted. I'm amazed no one else however noticed how easy it is to apply
to the livecd case, where seeks are drastically worse, and it is
drastically easier to get the filesystem sorted.
-dmc
Then as usage changes,
updates are issued and such the adaptive stuff would be able to keep the
preload system in as close to an optimal state?
That would seem to be the best of both worlds to me, but then again I'm
a self-admitted bumbling fool so what do I know.
- David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
