On Fri, Oct 12, 2007 at 01:05:18AM -0400, Warren Togami wrote:
> Bill Nottingham wrote:
> >Eric Sandeen (sandeen@xxxxxxxxxx) said:
> >>Matthias Clasen wrote:
> >>>On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> >>>
> >>>>Tossing a default list out there and hoping for the best probably won't
> >>>>work, at any rate.
> >>>So are we going to get your fixed lists into F8 ?
> >>>
> >>Well, part of the problem is that "my" fixed lists may not be everyone's
> >>fixed lists - I generated a custom list from *my* boot sequence. Coming
> >>up with a good default list that actually speeds *everyone's* boot time
> >>is another issue. If we think it's worth the 4 second or so boottime
> >>reduction, maybe some way to automatically generate the custom lists
> >>during firstboot might be an option. But then, they will rot over time...
> >
> >Given that, is there any reason to ship it on by default at this point?
> >
> >Bill
> >
>
> Relatively simple solution:
> 1) Ship readahead with template lists. This includes a list of commonly
> used stuff. It could include wildcards like /usr/lib*/firefox*/foo in
> order to handle multilib and version numbers changing.
> 2) During firstboot and occasionally after boot, something generates the
> actual readahead file lists based upon several factors like:
> - is the file actually installed?
> - is the service enabled?
> Later improvement:
> 3) Sometime later, more intelligent software could be included to help a
> user update their readahead lists based upon their own software usage
> patterns.
you needn't this scenario, you can simply boot with
init=/sbin/readahead-collector
it's probably better than develop and maintain something like
template lists.
The problem is something completely different than contents of
/etc/readahead.d/. The problem is that readahead (also with perfect
list of files) provides poor performance improvement.
We need to spend time with more promising tasks like better init
scripts, faster rhgb/X, swsuspend, fscache, ...
IMHO, the readahead package is poor workaround with no future. (I'm
author of more than 70% of the code.)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
