comments on KDE performance tips

[Lubos Lunak]

On Tuesday 14 of January 2003 06:26, Andrew Morton wrote:
> On Mon January 13 2003 05:40, Alexander Kellett wrote:
>
> One area which could benefit from kernel help is application startup.  Here
> is a `vmstat 1' trace during startup of the OpenOffice word processor:
>
 vmstat ... one learns something new every day :)
[snip]
>
> That's twenty six seconds of disk reading.  It's sustaining maybe 2.5
> megabytes per second off a disk which can do 25 megabytes/sec.
>
> Starting the application again, now that everything is in kernel pagecache
> takes about six seconds.  That's pure compute and is pretty gross.
>
> So there's almost twenty seconds worth of startup time here which could be
> shaved off by improving the IO access patterns.  This would require runtime
> analysis of the pagefault pattern, and re-layout of elf files based on that
> analysis.  Basically we want to pull each executable and shared library
> into pagecache in one great big slurp.

 Could the kernel (optionally) try to do something like this even without the 
analysis? Given that things in binaries are ordered rather chaotically from 
the usage order point of view, I think it could do much larger reads than it 
does now (now it just pages in single pages when needed, doesn't it). Reading 
whole libqt in one row probably could help in almost all cases. Or am I 
talking nonsense here?

>
> Kernel help would be needed for the instrumentation/analysis.  The reorg of
> the elf files would be a userspace issue.  One possible solution would be,
> once the elf files are reorganised, to change the libc dynamic loader so
> that it starts asynchronous reads against all the libraries which earlier
> instrumentation indicated will be needed.
>
> I assume these applications are also reading zillions of little config,
> font, icon, etc files as well.  That'll hurt.  One possible way of speeding
> that up would be for the application to maintain its own cache (on-disk) of
> all the info which it needed to start itself up.  So on the second startup
> it can all be read in in a single swipe.  Obviously, information coherency
> is an issue here.

 Unfortunately, there are many files that could be accessed by various KDE 
apps during their startup. This wouldn't be easy.

>
> It's all a fair bit of work, but *this* is where the gains are to be made.
> In the case of this app, the twenty six seconds can be potentially reduced
> to eight seconds by getting the IO scheduling right.
>
> Incidentally: be aware that the linker lays files out in strange manners -
> it seeks all over the file placing bits and pieces everywhere, so there is
> no correspondence between offset-into-file and offset-into-disk.  But if
> you then take the output of the linker and copy it somewhere else (ie:
> `make install') then the copied file _will_ have good linear layout.  This
> should be borne in mind when studying application startup times: don't try
> to measure the startup time for an executable or library which was laid out
> on disk by /usr/bin/ld.

 We have this only for Qt, don't we? Others are used after make install.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/