Pádraig Brady wrote:
> Marcus Furlong wrote:
>> Hi,
>>>> Having recently installed OpenSuse 10.1, I was surprised that it seems
>> much more responsive and snappier than a gentoo installation on the same
>> machine with processor-specific CFLAGS and prelinked binaries, etc. On
>> the OpenSuse site they actually state that prelinking in some cases slows
>> down applications, and they use an adaptive readahead technique. I was
>> wondering if anyone could enlighten me as to the differences between the
>> difference types of adaptive readahead that I've found:
>>>> * There is Behdad Esfahbod's version completed last year for Google's
>> SoC
>> (and used by Red Hat/Fedora I think)
>>>>http://preload.sourceforge.net/>>>>>> * There is SUSE's preload (which is not the same as the above one,
>> despite
>> having the same version number, I compared the source for both)
>>>>http://en.opensuse.org/SUPER_preloading>>http://www.novell.com/products/linuxpackages/suselinux/preload.html>>>>>> * Debian (and I suppose Ubuntu too?) uses ld.so.preload-manager
>>>>http://packages.debian.org/stable/admin/ld.so.preload-manager>>>>>> * Gentoo has readahead-list
>>http://packages.gentoo.org/packages/?category=sys-apps;name=readahead-list
>> ubuntu also has readahead-list. The above seem to do much the same thing:
> In idle periods (when entering password for example), preload the
> files off the disk that the user will probably need.
> An interesting related thing just released will align those
> files linearly in a dedicated partition, so that there will
> be no disk seeking when loading those files:
>http://lkml.org/lkml/2006/5/15/46
Interesting. Might give it a whirl.
>>> Ok so I was wondering if all the above are doing the same thing? If so,
>> does anyone know which one does it best? (SUSE 10.1 does seem very fast
>> to me, but I'm not sure about the other distros)
>>>> Also, there is Wu Fengguang's kernel version of adaptive readahead:
>>>>http://lkml.org/lkml/2006/5/27/71>>>> which seems to give a 3x speedup in a simple test =>
>>>>http://linux.inet.hr/adaptive_readahead_benchmark.html>>>> Does this do the same thing as the above programs? Will it obsolete them
>> if it accepted into the kernel?
>> This is more a runtime thing and is for automatically
> reading disk blocks (probably within a file) that you'll probably need.
So this and the fcache module you mentioned could be used together? Wu's
adaptive readahead could automatically read the disk blocks and fcache
could also then store those blocks on the cache partition? Or are they
mutually exclusive?
>>>>> There is also Con Kolivas's swap prefetch patchset at
>>http://kernel.kolivas.org and the aforementioned prelink, but AFAIK those
>> can be used along with adaptive readahead.
>> Make sure you don't confuse prelinking and preloading:
>http://crast.us/james/articles/prelink.php
Yeah, I already use prelinking (and have found it to speed up things,
possibly in my mind though! :-P) but on http://en.opensuse.org/SUPER, they
state:
"SUPER standard benchmark has been expanded with some additional tests based
on our 1 CD install. Some areas like booting .are improved, preloading has
made already a big difference in application startup time and prelinking is
actually making things certainly slower again. Very interesting results
indeed. Check it out. Coolo sure was right about prelink how could I have
doubted the master?"
So, I started looking around at the various preloading programs. Anyone know
the best way of benchmarking these things? bootchart and `time` come to
mind.
>> Pádraig.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!