[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Preloading [WAS: Re: SuSE Project SUPER]

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 redhat com> 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.


 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]