filesystem optimizations (Re: comments on KDE performance tips)

[Roger Larsson]

On Thursday 16 January 2003 16:07, Waldo Bastian wrote:
> On Thursday 16 January 2003 14:29, Lubos Lunak wrote:
> > > So there's almost twenty seconds worth of startup time here which cou=
ld
> > > 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 witho=
ut
> > the analysis? Given that things in binaries are ordered rather chaotica=
lly
> > from the usage order point of view, I think it could do much larger rea=
ds
> > 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?
>=20
> I once discussed this with a kernel hacker and I believe reads are done i=
n=20
> blocks of 64Kb, so that would be 16 pages in a row.=20

But that is if you use read ahead. And read ahead is only used for sequenti=
al
reads. If you have a library that you page in "random" pages. You will
not get the benefit... the kernel can not guess that you will need most of =
the
file eventually... Another problem is that even sequential reads will break
down if there is a lot of disk accesses at the same time. [Read from multip=
le
threads reading at the same time, konqueror and kio_slaves? - KDE uses
quite a number of processes/threads. Try to keep them from disturbing each
other]
The kernel has in this case very difficult to decide that it should read ah=
ead
a page that you might use sometime in the distant future instead of reading
data from another page that is needed right now...

>=20
> I think it is possible to let the linker tell the kernel that the whole=20
thing=20
> should be read, but that's a suboptimal solution in that you read a lot o=
f=20
> stuff you rather not read. The best solution is to read what you need in =
one=20
> go, and nothing of the stuff that you don't need. Such solution would mea=
n=20
> that you put all the stuff that you need (at startup) in one continguous=
=20
part=20
> of your lib and then the (runtime) linker should tell the kernel that it=
=20
must=20
> read all that in.

The nice thing is that once you start a program it reads more or less exact=
ly
the same stuff from the filesystem. If it, or another program, records this=
=20
info - can be done with strace - and plays it back so that reads are done
immediately when the data is requested it might feel like a win but now
you have to be very careful not to create two threads that compete with
eachother. And you will still do "random" accesses. And since the original
program will get cached data all the time it will quickly catch up.
[I have tried this]

Next step is to analyze the read patterns to find a more filesystem
friendly way. It can be done, but it is a application level problem.
[it could be possible to store typical access patterns for each file but
you will stall on the first access, better to handle this at application
level]

/RogerL

PS
	I remember an attempt to link files together. When one was read
	the kernel automatically started with the other one. It was not
	a win, at least not for kernel compilations.
DS

=2D-=20
Roger Larsson
Skellefte=E5
Sweden