All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>, David Rientjes <rientjes@google.com>,
	Nishanth Aravamudan <nacc@linux.vnet.ibm.com>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm readahead: Fix sys_readahead breakage by reverting 2MB limit (bug 79111)
Date: Fri, 04 Jul 2014 00:26:41 +0530	[thread overview]
Message-ID: <53B5A769.5030108@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFyqK90YJkjtHR2QGFt4Mvn=mj8a4FkB_8nbTTj3=jp3NA@mail.gmail.com>

On 07/04/2014 12:23 AM, Linus Torvalds wrote:
> On Thu, Jul 3, 2014 at 11:38 AM, Raghavendra K T
> <raghavendra.kt@linux.vnet.ibm.com> wrote:
>>
>> Okay, how about something like 256MB? I would be happy to send a patch
>> for that change.
>
> I'd like to see some performance numbers. I know at least Fedora uses
> "readahead()" in the startup scripts, do we have any performance
> numbers for that?
>
> Also, I think 256MB is actually excessive. People still do have really
> slow devices out there. USB-2 is still common, and drives that read at
> 15MB/s are not unusual. Do we really want to do readahead() that can
> take tens of seconds (and *will* take tens of seconds sycnhronously,
> because the IO requests fill up).
>
> So I wouldn't go from 2 to 256. That seems like an excessive jump. I
> was more thinking in the 4-8MB range. But even then, I think we should
> always have technical reasons (ie preferably numbers) for the change,
> not just randomly change it.

Okay. I 'll take some time to do the analysis. I think we also should
keep in mind of possible remote readahead that would cause unnecessary
penalty.





--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>, David Rientjes <rientjes@google.com>,
	Nishanth Aravamudan <nacc@linux.vnet.ibm.com>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm readahead: Fix sys_readahead breakage by reverting 2MB limit (bug 79111)
Date: Fri, 04 Jul 2014 00:26:41 +0530	[thread overview]
Message-ID: <53B5A769.5030108@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFyqK90YJkjtHR2QGFt4Mvn=mj8a4FkB_8nbTTj3=jp3NA@mail.gmail.com>

On 07/04/2014 12:23 AM, Linus Torvalds wrote:
> On Thu, Jul 3, 2014 at 11:38 AM, Raghavendra K T
> <raghavendra.kt@linux.vnet.ibm.com> wrote:
>>
>> Okay, how about something like 256MB? I would be happy to send a patch
>> for that change.
>
> I'd like to see some performance numbers. I know at least Fedora uses
> "readahead()" in the startup scripts, do we have any performance
> numbers for that?
>
> Also, I think 256MB is actually excessive. People still do have really
> slow devices out there. USB-2 is still common, and drives that read at
> 15MB/s are not unusual. Do we really want to do readahead() that can
> take tens of seconds (and *will* take tens of seconds sycnhronously,
> because the IO requests fill up).
>
> So I wouldn't go from 2 to 256. That seems like an excessive jump. I
> was more thinking in the 4-8MB range. But even then, I think we should
> always have technical reasons (ie preferably numbers) for the change,
> not just randomly change it.

Okay. I 'll take some time to do the analysis. I think we also should
keep in mind of possible remote readahead that would cause unnecessary
penalty.






  reply	other threads:[~2014-07-03 19:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-03 13:02 [PATCH] mm readahead: Fix sys_readahead breakage by reverting 2MB limit (bug 79111) Raghavendra K T
2014-07-03 13:02 ` Raghavendra K T
2014-07-03 15:41 ` Linus Torvalds
2014-07-03 15:41   ` Linus Torvalds
2014-07-03 18:11   ` Raghavendra K T
2014-07-03 18:11     ` Raghavendra K T
2014-07-03 18:22     ` Linus Torvalds
2014-07-03 18:22       ` Linus Torvalds
2014-07-03 18:29       ` Linus Torvalds
2014-07-03 18:29         ` Linus Torvalds
2014-07-03 18:38         ` Raghavendra K T
2014-07-03 18:38           ` Raghavendra K T
2014-07-03 18:50           ` Raghavendra K T
2014-07-03 18:50             ` Raghavendra K T
2014-07-03 18:53           ` Linus Torvalds
2014-07-03 18:53             ` Linus Torvalds
2014-07-03 18:56             ` Raghavendra K T [this message]
2014-07-03 18:56               ` Raghavendra K T
2014-07-03 19:05             ` Dave Jones
2014-07-03 19:05               ` Dave Jones
2014-07-03 19:43         ` John Stoffel
2014-07-03 19:43           ` John Stoffel
2014-07-03 21:58           ` Linus Torvalds
2014-07-03 21:58             ` Linus Torvalds
2014-10-03 20:57             ` Rafael Aquini
2014-10-03 20:57               ` Rafael Aquini
2014-07-03 18:35       ` Raghavendra K T
2014-07-03 18:35         ` 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=53B5A769.5030108@linux.vnet.ibm.com \
    --to=raghavendra.kt@linux.vnet.ibm.com \
    --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=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --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 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.