From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Taras Glek <tglek@mozilla.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Downsides to madvise/fadvise(willneed) for application startup
Date: Wed, 7 Apr 2010 16:13:51 +0800 [thread overview]
Message-ID: <20100407081351.GA20322@localhost> (raw)
In-Reply-To: <g2q28c262361004070106le671ad63u965e8137ad2e4f41@mail.gmail.com>
Minchan,
> A few month ago, I saw your patch about enhancing readahead.
> At that time, many guys tested several size of USB and SSD which are
> consist of nand device.
> The result is good if we does readahead untile some crossover point.
> So I think we need readahead about file I/O in non-rotation device, too.
>
> But startup latency is important than file I/O performance in some machine.
> With analysis at that time, code readahead of application affected slow startup.
> In addition, during bootup, cache hit ratio was very small.
>
> So I hoped we can disable readahead just only code section(ie, roughly
> exec vma's filemap fault). :)
>
> I don't want you to solve this problem right now.
> Just let you understand embedded system's some problem
> for enhancing readahead in future. :)
Yeah, I've never heard of such a demand, definitely good to know it!
Thanks,
Fengguang
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Taras Glek <tglek@mozilla.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Downsides to madvise/fadvise(willneed) for application startup
Date: Wed, 7 Apr 2010 16:13:51 +0800 [thread overview]
Message-ID: <20100407081351.GA20322@localhost> (raw)
In-Reply-To: <g2q28c262361004070106le671ad63u965e8137ad2e4f41@mail.gmail.com>
Minchan,
> A few month ago, I saw your patch about enhancing readahead.
> At that time, many guys tested several size of USB and SSD which are
> consist of nand device.
> The result is good if we does readahead untile some crossover point.
> So I think we need readahead about file I/O in non-rotation device, too.
>
> But startup latency is important than file I/O performance in some machine.
> With analysis at that time, code readahead of application affected slow startup.
> In addition, during bootup, cache hit ratio was very small.
>
> So I hoped we can disable readahead just only code section(ie, roughly
> exec vma's filemap fault). :)
>
> I don't want you to solve this problem right now.
> Just let you understand embedded system's some problem
> for enhancing readahead in future. :)
Yeah, I've never heard of such a demand, definitely good to know it!
Thanks,
Fengguang
--
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>
next prev parent reply other threads:[~2010-04-07 8:14 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
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 [this message]
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=20100407081351.GA20322@localhost \
--to=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.com \
--cc=tglek@mozilla.com \
/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.