Steven Cole <elenstev@mesatop.com> wrote:
>
> On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > >
> > > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > > This means that when an executable is first mapped in, the kernel will
> > > > slurp the whole thing off disk in one hit. Some IO changes were made to
> > > > speed this up.
> > >
> > > Does this just pull in text and data, or will it pull any debug sections
> > > too? That could fill memory with a lot of useless junk.
> > >
> >
> > Just text, I expect. Unless glibc is mapping debug info with PROT_EXEC ;)
> >
> > It's just a fun hack. Should be done in glibc.
>
> Well, fun hack or glibc to-do list candidate, I hope it doesn't get
> forgotten.
I have to pull the odd party trick to get people to test -mm kernels.
> I am happy to confirm that it did speed up the initial
> launch time of Open Office from 20 seconds (2.5-bk) to 11 seconds (-mm6)
> and Mozilla from 10 seconds (2.5-bk) to 6 seconds (-mm6).
OK, thanks for confirming that. Both these apps are *very* compute-intensive
at startup. Try starting them when everything is in cache... The
proportional benefits for saner apps wil be larger.
As for glibc, yup, the two-liner which I mentioned is a good start. Finer
tuning would involve looking at the data segments, dlopen(), etc. A fun
project.
One subtlety: the linker (ld) lays files out very poorly. So the prefaulting
trick will not help much when run against an executable which was written by
ld. But if you've copied it into /bin (make install) then it will work well.
That's something to watch out for.
Doing it in madvise may work better actually. madvise will pull the pages
into pagecache and leave them on the inactive list. A subsequent minor fault
will activate the pages. So the unneeded pages get thrown away quickly.
Which is exactly what we want.
However -mm6 actually maps all the pages into the process's pagetables at
mmap() time. That saves the cost of thousands of minor pagefaults, but it
means that the pages which we didn't really want will take longer to be
reclaimed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:38 EST