From: Linus Torvalds <torvalds@linux-foundation.org>
To: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>,
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
David Cohen <david.a.cohen@linux.intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Damien Ramonda <damien.ramonda@intel.com>,
Jan Kara <jack@suse.cz>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Thu, 13 Feb 2014 16:37:53 -0800 [thread overview]
Message-ID: <CA+55aFwH8BqyLSqyLL7g-08nOtnOrJ9vKj4ebiSqrxc5ooEjLw@mail.gmail.com> (raw)
In-Reply-To: <20140214001438.GB1651@linux.vnet.ibm.com>
Is this whole thread still just for the crazy and pointless
"max_sane_readahead()"?
Or is there some *real* reason we should care?
Because if it really is just for max_sane_readahead(), then for the
love of God, let us just do this
unsigned long max_sane_readahead(unsigned long nr)
{
return min(nr, 128);
}
and bury this whole idiotic thread.
Seriously, if your IO subsystem needs more than 512kB of read-ahead to
get full performance, your IO subsystem is just bad, and has latencies
that are long enough that you should just replace it. There's no real
reason to bend over backwards for that, and the whole complexity and
fragility of the insane "let's try to figure out how much memory this
node has" is just not worth it. The read-ahead should be small enough
that we should never need to care, and large enough that you get
reasonable IO throughput. The above does that.
Goddammit, there's a reason the whole "Gordian knot" parable is
famous. We're making this all too damn complicated FOR NO GOOD REASON.
Just cut the rope, people. Our aim is not to generate some kind of job
security by making things as complicated as possible.
Linus
On Thu, Feb 13, 2014 at 4:14 PM, Nishanth Aravamudan
<nacc@linux.vnet.ibm.com> wrote:
>
> I'm working on this latter bit now. I tried to mirror ia64, but it looks
> like they have CONFIG_USER_PERCPU_NUMA_NODE_ID, which powerpc doesn't.
> It seems like CONFIG_USER_PERCPU_NUMA_NODE_ID and
> CONFIG_HAVE_MEMORYLESS_NODES should be tied together in Kconfig?
>
> I'll keep working, but would appreciate any further insight.
>
> -Nish
>
--
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:[~2014-02-14 0:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 10:53 Raghavendra K T
2014-02-03 8:30 ` Raghavendra K T
2014-02-06 22:51 ` Andrew Morton
2014-02-06 22:58 ` David Rientjes
2014-02-06 23:22 ` Andrew Morton
2014-02-06 23:48 ` David Rientjes
2014-02-06 23:58 ` David Rientjes
2014-02-07 10:42 ` Raghavendra K T
2014-02-07 20:41 ` David Rientjes
2014-02-10 8:21 ` Raghavendra K T
2014-02-10 10:05 ` David Rientjes
2014-02-10 12:25 ` Raghavendra K T
2014-02-10 21:35 ` David Rientjes
2014-02-13 7:07 ` Raghavendra K T
2014-02-13 8:05 ` David Rientjes
2014-02-13 10:04 ` Raghavendra K T
2014-02-13 22:41 ` David Rientjes
2014-02-14 0:14 ` Nishanth Aravamudan
2014-02-14 0:37 ` Linus Torvalds [this message]
2014-02-14 0:45 ` Andrew Morton
2014-02-14 4:32 ` Nishanth Aravamudan
2014-02-14 10:54 ` David Rientjes
2014-02-17 19:28 ` Nishanth Aravamudan
2014-02-17 23:14 ` David Rientjes
2014-02-18 1:31 ` Nishanth Aravamudan
2014-02-17 22:59 ` Linus Torvalds
2014-02-14 7:43 ` Jan Kara
2014-02-17 22:57 ` Linus Torvalds
2014-02-14 5:47 ` Nishanth Aravamudan
2014-02-13 21:06 ` Andrew Morton
2014-02-13 21:42 ` Nishanth Aravamudan
2014-02-10 8:29 ` [RFC PATCH V5 RESEND] " Raghavendra K T
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=CA+55aFwH8BqyLSqyLL7g-08nOtnOrJ9vKj4ebiSqrxc5ooEjLw@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=damien.ramonda@intel.com \
--cc=david.a.cohen@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nacc@linux.vnet.ibm.com \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=rientjes@google.com \
--cc=viro@zeniv.linux.org.uk \
/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