From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270342AbTHGQ0S (ORCPT ); Thu, 7 Aug 2003 12:26:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270345AbTHGQ0R (ORCPT ); Thu, 7 Aug 2003 12:26:17 -0400 Received: from fw.osdl.org ([65.172.181.6]:10890 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S270342AbTHGQ0N (ORCPT ); Thu, 7 Aug 2003 12:26:13 -0400 Date: Thu, 7 Aug 2003 09:28:00 -0700 From: Andrew Morton To: Badari Pulavarty Cc: suparna@in.ibm.com, linux-kernel@vger.kernel.org, linux-aio@kvack.org Subject: Re: [PATCH][2.6-mm] Readahead issues and AIO read speedup Message-Id: <20030807092800.58335e84.akpm@osdl.org> In-Reply-To: <200308070901.01119.pbadari@us.ibm.com> References: <20030807100120.GA5170@in.ibm.com> <200308070901.01119.pbadari@us.ibm.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-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 Badari Pulavarty wrote: > > I noticed the exact same thing while testing on database benchmark > on filesystems (without AIO). I added instrumentation in scsi layer to > record the IO pattern and I found that we are doing lots of (4million) > 4K reads, in my benchmark run. I was tracing that and found that all > those reads are generated by slow read path, since readahead window > is maximally shrunk. When I forced the readahead code to read 16k > (my database pagesize), in case ra window closed - I see 20% improvement > in my benchmark. I asked "Ramchandra Pai" (linuxram@us.ibm.com) > to investigate it further. But if all the file's pages are already in pagecache (a common case) this patched kernel will consume extra CPU pointlessly poking away at pagecache. Reliably shrinking the window to zero is important for this reason. If the database pagesize is 16k then the application should be submitting 16k reads, yes? If so then these should not be creating 4k requests at the device layer! So what we need to do is to ensure that at least those 16k worth of pages are submitted in a single chunk. Without blowing CPU if everything is cached. Tricky. I'll take a look at what's going on. Another relevant constraint here (and there are lots of subtle constraints in readahead) is that often database files are fragmented all over the disk, because they were laid out that way (depends on the database and how it was set up). In this case, any extra readahead is a disaster because it incurs extra seeks, needlessly.