All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taras Glek <tglek@mozilla.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Downsides to madvise/fadvise(willneed) for application startup
Date: Tue, 06 Apr 2010 14:57:30 -0700	[thread overview]
Message-ID: <4BBBAE4A.7070000@mozilla.com> (raw)
In-Reply-To: <20100406095135.GB5183@cmpxchg.org>

On 04/06/2010 02:51 AM, Johannes Weiner wrote:
> On Mon, Apr 05, 2010 at 03:43:02PM -0700, Taras Glek wrote:
>    
>> 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?
>>      
> It will throttle based on memory pressure.  In idle situations it will
> eat your file cache, however, to satisfy the request.
>    
Define idle situations. Do you mean that madv(willneed) will aggresively 
readahead, but only while cpu(or disk?) is idle?
I am trying to optimize application startup which means that the cpu is 
busy while not blocked on io.
> Now, the file cache should be much bigger than the amount of unneeded
> pages you prefault with the hint over the whole library, so I guess the
> benefit of prefaulting the right pages outweighs the downside of evicting
> some cache for unused library pages.
>    
> Still, it's a workaround for deficits in the demand-paging/readahead
> heuristics and thus a bit ugly, I feel.  Maybe Wu can help.
>
>    
Can't wait to hear the juicy details.
>> Also, once an application is started is it reasonable to keep it
>> madvise(WILLNEED)ed or should the madvise flags be reset?
>>      
> It's a one-time operation that starts immediate readahead, no permanent
> changes are done.
>    
I may be measuring this wrong, but in my experience the only change 
madvise(willneed) does in increase the length parameter to 
__do_page_cache_readahead(). My script is at 
http://hg.mozilla.org/users/tglek_mozilla.com/startup/file/6453ad2a7906/kernelio.stp 
.


Taras

WARNING: multiple messages have this Message-ID (diff)
From: Taras Glek <tglek@mozilla.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Downsides to madvise/fadvise(willneed) for application startup
Date: Tue, 06 Apr 2010 14:57:30 -0700	[thread overview]
Message-ID: <4BBBAE4A.7070000@mozilla.com> (raw)
In-Reply-To: <20100406095135.GB5183@cmpxchg.org>

On 04/06/2010 02:51 AM, Johannes Weiner wrote:
> On Mon, Apr 05, 2010 at 03:43:02PM -0700, Taras Glek wrote:
>    
>> 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?
>>      
> It will throttle based on memory pressure.  In idle situations it will
> eat your file cache, however, to satisfy the request.
>    
Define idle situations. Do you mean that madv(willneed) will aggresively 
readahead, but only while cpu(or disk?) is idle?
I am trying to optimize application startup which means that the cpu is 
busy while not blocked on io.
> Now, the file cache should be much bigger than the amount of unneeded
> pages you prefault with the hint over the whole library, so I guess the
> benefit of prefaulting the right pages outweighs the downside of evicting
> some cache for unused library pages.
>    
> Still, it's a workaround for deficits in the demand-paging/readahead
> heuristics and thus a bit ugly, I feel.  Maybe Wu can help.
>
>    
Can't wait to hear the juicy details.
>> Also, once an application is started is it reasonable to keep it
>> madvise(WILLNEED)ed or should the madvise flags be reset?
>>      
> It's a one-time operation that starts immediate readahead, no permanent
> changes are done.
>    
I may be measuring this wrong, but in my experience the only change 
madvise(willneed) does in increase the length parameter to 
__do_page_cache_readahead(). My script is at 
http://hg.mozilla.org/users/tglek_mozilla.com/startup/file/6453ad2a7906/kernelio.stp 
.


Taras

--
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:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-04-06 21:57 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 22:43 Downsides to madvise/fadvise(willneed) for application startup Taras Glek
2010-04-05 23:17 ` 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  9:51   ` Johannes Weiner
2010-04-06 21:57   ` Taras Glek [this message]
2010-04-06 21:57     ` Taras Glek
2010-04-06 22:26     ` Johannes Weiner
2010-04-06 22:26       ` Johannes Weiner
2010-04-06 22:39       ` Taras Glek
2010-04-06 22:39         ` Taras Glek
2010-04-07  2:24   ` Wu Fengguang
2010-04-07  2:24     ` Wu Fengguang
2010-04-07  2:54     ` Taras Glek
2010-04-07  2:54       ` Taras Glek
2010-04-07  4:06       ` Minchan Kim
2010-04-07  4:06         ` Minchan Kim
2010-04-07  7:14         ` Wu Fengguang
2010-04-07  7:14           ` Wu Fengguang
2010-04-07  7:33           ` Minchan Kim
2010-04-07  7:33             ` Minchan Kim
2010-04-07  7:47             ` Wu Fengguang
2010-04-07  7:47               ` Wu Fengguang
2010-04-07  8:06               ` Minchan Kim
2010-04-07  8:06                 ` Minchan Kim
2010-04-07  8:13                 ` Wu Fengguang
2010-04-07  8:13                   ` Wu Fengguang
2010-04-07  7:38       ` Wu Fengguang
2010-04-07  7:38         ` Wu Fengguang
2010-04-08 17:44         ` Taras Glek
2010-04-08 17:44           ` Taras Glek
2010-04-12  2:27           ` Wu Fengguang
2010-04-12  2:27             ` Wu Fengguang
2010-04-12  3:25             ` Minchan Kim
2010-04-12  3:25               ` Minchan Kim
2010-04-12  4:58               ` Wu Fengguang
2010-04-12  4:58                 ` Wu Fengguang
2010-04-12  4:43             ` drepper
2010-04-12  4:46               ` Taras Glek
2010-04-12  4:46                 ` Taras Glek
2010-04-12  4:50               ` Wu Fengguang
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=4BBBAE4A.7070000@mozilla.com \
    --to=tglek@mozilla.com \
    --cc=fengguang.wu@intel.com \
    --cc=hannes@cmpxchg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.