public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Taras Glek <tglek@mozilla.com>
To: linux-kernel@vger.kernel.org
Subject: Downsides to madvise/fadvise(willneed) for application startup
Date: Mon, 05 Apr 2010 15:43:02 -0700	[thread overview]
Message-ID: <4BBA6776.5060804@mozilla.com> (raw)

Hello,
I am working on improving Mozilla startup times. It turns out that page 
faults(caused by lack of cooperation between user/kernelspace) are the 
main cause of slow startup. I need some insights from someone who 
understands linux vm behavior.

Current Situation:
The dynamic linker mmap()s  executable and data sections of our 
executable but it doesn't call madvise().
By default page faults trigger 131072byte reads. To make matters worse, 
the compile-time linker + gcc lay out code in a manner that does not 
correspond to how the resulting executable will be executed(ie the 
layout is basically random). This means that during startup 15-40mb 
binaries are read in basically random fashion. Even if one orders the 
binary optimally, throughput is still suboptimal due to the puny readahead.

IO Hints:
Fortunately when one specifies madvise(WILLNEED) pagefaults trigger 2mb 
reads and a binary that tends to take 110 page faults(ie program stops 
execution and waits for disk) can be reduced down to 6. This has the 
potential to double application startup of large apps without any clear 
downsides. Suse ships their glibc with a dynamic linker patch to 
fadvise() dynamic libraries(not sure why they switched from doing 
madvise before).

I filed a glibc bug about this at 
http://sourceware.org/bugzilla/show_bug.cgi?id=11431 . Uli commented 
with his concern about wasting memory resources. What is the impact of 
madvise(WILLNEED) or the fadvise equivalent on systems under memory 
pressure? Does the kernel simply start ignoring these hints?

Also, once an application is started is it reasonable to keep it 
madvise(WILLNEED)ed or should the madvise flags be reset?

Perhaps the kernel could monitor the page-in patterns to increase the 
readahead sizes? This may already happen, I've noticed that a handful of 
pagefaults trigger > 131072bytes of IO, perhaps this just needs tweaking.

Thanks,
Taras Glek

PS. For more details on this issue see my blog at 
https://blog.mozilla.com/tglek/

             reply	other threads:[~2010-04-05 23:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 22:43 Taras Glek [this message]
2010-04-05 23:17 ` Downsides to madvise/fadvise(willneed) for application startup Dave Chinner
2010-04-05 23:52 ` Roland Dreier
2010-04-06 22:09   ` Taras Glek
2010-04-06  9:51 ` Johannes Weiner
2010-04-06 21:57   ` Taras Glek
2010-04-06 22:26     ` Johannes Weiner
2010-04-06 22:39       ` Taras Glek
2010-04-07  2:24   ` Wu Fengguang
2010-04-07  2:54     ` Taras Glek
2010-04-07  4:06       ` Minchan Kim
2010-04-07  7:14         ` Wu Fengguang
2010-04-07  7:33           ` Minchan Kim
2010-04-07  7:47             ` Wu Fengguang
2010-04-07  8:06               ` Minchan Kim
2010-04-07  8:13                 ` Wu Fengguang
2010-04-07  7:38       ` Wu Fengguang
2010-04-08 17:44         ` Taras Glek
2010-04-12  2:27           ` Wu Fengguang
2010-04-12  3:25             ` Minchan Kim
2010-04-12  4:58               ` Wu Fengguang
2010-04-12  4:43             ` drepper
2010-04-12  4:46               ` Taras Glek
2010-04-12  4:50               ` Wu Fengguang
2010-04-12  8:50 ` Andi Kleen
2010-04-15 22:53 ` Andrew Morton
2010-04-15 23:21   ` Zan Lynx
2010-04-15 20:42     ` Andrew Morton
2010-04-16 11:41     ` Andi Kleen
2010-04-16 12:23       ` Theodore Tso
2010-04-16 12:23       ` Theodore Tso
2010-04-16  0:41   ` Taras Glek
2010-04-15 22:21     ` Andrew Morton
2010-04-16  2:37       ` Taras Glek
2010-04-16 11:40   ` Andi Kleen

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=4BBA6776.5060804@mozilla.com \
    --to=tglek@mozilla.com \
    --cc=linux-kernel@vger.kernel.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