Re: Strange IDE performance change in 2.6.1-rc1 (again)

[Andrew Morton <akpm@osdl.org>]

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.