Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S266403AbUAIBQ1 (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 8 Jan 2004 20:16:27 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266404AbUAIBQ1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 8 Jan 2004 20:16:27 -0500
Received: from fw.osdl.org ([65.172.181.6]:21894 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id S266403AbUAIBQV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 8 Jan 2004 20:16:21 -0500
Date: Thu, 8 Jan 2004 17:17:28 -0800
From: Andrew Morton <akpm@osdl.org>
To: Ram Pai <linuxram@us.ibm.com>
Cc: ornati@lycos.it, gandalf@wlug.westbo.se, linux-kernel@vger.kernel.org
Subject: Re: Strange IDE performance change in 2.6.1-rc1 (again)
Message-Id: <20040108171728.54a72cf7.akpm@osdl.org>
In-Reply-To: <1073610357.12720.20.camel@dyn319250.beaverton.ibm.com>
References: <200401021658.41384.ornati@lycos.it>
	<200401071559.16130.ornati@lycos.it>
	<1073503421.10018.17.camel@dyn319250.beaverton.ibm.com>
	<200401072112.35334.ornati@lycos.it>
	<20040107155729.7e737c36.akpm@osdl.org>
	<1073610357.12720.20.camel@dyn319250.beaverton.ibm.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2134
Lines: 53

Ram Pai <linuxram@us.ibm.com> wrote:
>
> Ok, I did some analysis and found that 'hdparm -t <device> '
> generates reads which are of size 1M. This means 256 page requests are
> generated by a single read.  
> 
> do_generic_mapping_read()  gets the request to read 256 pages. But with
> the latest change, this function calls do_pagecahce_readahead() to keep 
> 256 pages ready in cache. And after having done that
> do_generic_mapping_read() tries to access those 256 pages.
> But by then some of the pages may have been replaced under low pagecache
> conditions. Hence we end up spending extra time reading those pages
> again into the page cache.
> 
> I think the same problem must exist while reading files too. Paulo
> Ornati used cat command to read the file. cat just generates 1 page
> request per read and hence the problem did not show up. The problem must
> show up if 'dd if=big_file of=/dev/null bs=1M count=256' is used.
> 
> To conclude, I think the bug is with the changes to filemap.c 
> If the changes are reverted the regression seen with blockdevices should
> go away.
> 
> Well this is my theory, somebody should validate it,

One megabyte seems like far too litte memory to be triggering the effect
which you describe.  But yes, the risk is certainly there.

You could verify this with:

--- 25/mm/filemap.c~a	Thu Jan  8 17:15:57 2004
+++ 25-akpm/mm/filemap.c	Thu Jan  8 17:16:06 2004
@@ -629,8 +629,10 @@ find_page:
 			handle_ra_miss(mapping, ra, index);
 			goto no_cached_page;
 		}
-		if (!PageUptodate(page))
+		if (!PageUptodate(page)) {
+			printk("eek!\n");
 			goto page_not_up_to_date;
+		}
 page_ok:
 		/* If users can be writing to this page using arbitrary
 		 * virtual addresses, take care about potential aliasing


But still, that up-front readahead loop is undesirable and yes, it would be
better if we could go back to the original design in there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/