public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Pratt <slpratt@austin.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Simplified Readahead
Date: Mon, 27 Sep 2004 15:07:01 -0500	[thread overview]
Message-ID: <415872E5.1050004@austin.ibm.com> (raw)
In-Reply-To: <1096310537.11845.33.camel@dyn319181.beaverton.ibm.com>

Ram Pai wrote:

>On Mon, 2004-09-27 at 08:30, Steven Pratt wrote:
>  
>
>>Ram Pai wrote:
>>    
>>
>>>On Fri, 24 Sep 2004, Ram Pai wrote: 
>>>
>>>      
>>>
>>>>On Thu, 23 Sep 2004, Steven Pratt wrote:
>>>>   
>>>>        
>>>>
>
> ..snip..
>  
>
>>>To summarize you noticed 3 problems:
>>>
>>>1. page cache hits not handled properly.
>>>2. readahead thrashing not accounted.
>>>3. read congestion not accounted.
>>> 
>>>
>>>      
>>>
>>Yes.
>>    
>>
>>>Currently both the patches do not handle all the above cases.
>>> 
>>>
>>>      
>>>
>>No, thrashing was handled in the first patch, and both thrashing and 
>>page cache hits are handled in the second.  Also, it seems to be the 
>>consensus that on normal I/O ignoring queue congestion is the right 
>>behavior.
>>
>>    
>>
>>>So if your patch performs much better than the current one, than
>>>it is the winner anyway.   But past experience has shown that some
>>>benchmark gets a hit for any small change. This happens to be tooo big
>>>a change.
>>>
>>>      
>>>
>>I agree, we need more people to test this.
>>
>>    
>>
>
>
>I will fix the 3 problems you discovered in the current code.
>And lets  compare the two results.
>
Ok, great.

>  However you have more features in
>your patch which will be the differentiating factor between the two
>versions.
>
>1. exponential increase and decrease of window size 
>2. overlapped read of current window and readahead window.
>3. fixed slow-read path.
>4. anything else?
>	
>
No, I think that is it.

>The readsize parameter comes in handy to incorporate the
>the above features.
>  
>
Yes, without it I think you still need to do the average calculations 
that you do today.

Also, remember that we did not re-write the readahead code just for the 
fun of it.  It was simply the most efficient way we came up with to 
address the current issues as well as add the new features.  The actual 
I/O patterns generated are not that different in most cases.

Steve



  reply	other threads:[~2004-09-27 20:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23 16:06 [PATCH/RFC] Simplified Readahead Steven Pratt
2004-09-23 22:14 ` Joel Schopp
2004-09-24  0:21 ` Nick Piggin
2004-09-24  2:42 ` Andrew Morton
2004-09-24 15:40   ` Steven Pratt
2004-09-24 16:16     ` Nick Piggin
2004-09-24 16:48       ` Steven Pratt
2004-09-24 22:05     ` Andrew Morton
2004-09-24 22:43       ` Steven Pratt
2004-09-24 23:01         ` Andrew Morton
2004-09-27 15:39           ` Steven Pratt
2004-09-27 19:26             ` Andrew Morton
2004-09-28 10:13               ` Jens Axboe
2004-09-24 22:55       ` Steven Pratt
2004-09-27 20:29         ` Ray Bryant
2004-09-27 21:04           ` Steven Pratt
2004-09-25  0:45       ` Nick Piggin
2004-09-25  1:01 ` Ram Pai
2004-09-25  6:07   ` Ram Pai
2004-09-27 15:30     ` Steven Pratt
2004-09-27 18:42       ` Ram Pai
2004-09-27 20:07         ` Steven Pratt [this message]
2004-09-29 18:46           ` Ram Pai
2004-09-29 22:33             ` Steven Pratt
2004-09-29 23:13               ` Andreas Dilger
2004-09-30  2:26                 ` Ram Pai
2004-09-30  5:29                   ` Andrew Morton
2004-09-30 20:20                 ` Stephen C. Tweedie
2004-09-30  1:12               ` Ram Pai
2004-10-01 21:02             ` Steven Pratt
2004-10-05 17:52               ` Ram Pai
     [not found] <372479081@toto.iv>
2004-09-24  5:00 ` Peter Chubb
2004-09-24 22:57   ` Steven Pratt

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=415872E5.1050004@austin.ibm.com \
    --to=slpratt@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox