linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Steven Cole <elenstev@mesatop.com>
Cc: jeremy@goop.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.64-mm6
Date: Thu, 13 Mar 2003 19:28:09 -0800	[thread overview]
Message-ID: <20030313192809.17301709.akpm@digeo.com> (raw)
In-Reply-To: <1047611104.14782.5410.camel@spc1.mesatop.com>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

  reply	other threads:[~2003-03-14  3:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-13 11:26 2.5.64-mm6 Andrew Morton
2003-03-13 16:23 ` 2.5.64-mm6 Jeremy Fitzhardinge
2003-03-13 19:34   ` 2.5.64-mm6 Andrew Morton
2003-03-13 20:07     ` 2.5.64-mm6 Roger Larsson
2003-03-14  3:04     ` 2.5.64-mm6 Steven Cole
2003-03-14  3:28       ` Andrew Morton [this message]
2003-03-14  3:46         ` 2.5.64-mm6 Shawn
2003-03-14  3:51           ` 2.5.64-mm6 Andrew Morton
2003-03-14  3:56           ` 2.5.64-mm6 Robert Love
2003-03-13 20:35 ` 2.5.64-mm6 Thomas Molina
2003-03-14  9:29 ` 2.5.64-mm6 Alexander Hoogerhuis
2003-03-14 11:55   ` 2.5.64-mm6 Andrew Morton
2003-03-15  8:38     ` 2.5.64-mm6 Alexander Hoogerhuis
2003-03-14 12:01 ` 2.5.64-mm6 Helge Hafting
2003-03-14 12:14   ` 2.5.64-mm6 Andrew Morton
2003-03-14 20:38 ` 2.5.64-mm6 Eli Carter
2003-03-14 20:53   ` 2.5.64-mm6 Andrew Morton
2003-03-14 22:01     ` 2.5.64-mm6 Eli Carter
2003-03-14 22:21       ` 2.5.64-mm6 Andrew Morton
2003-03-13 13:42 2.5.64-mm6 Felipe Alfaro Solana
2003-03-13 21:49 2.5.64-mm6 Felipe Alfaro Solana
2003-03-14  0:23 ` 2.5.64-mm6 Thomas Molina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030313192809.17301709.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=elenstev@mesatop.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox