Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753951AbZC3RI1 (ORCPT ); Mon, 30 Mar 2009 13:08:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752160AbZC3RIS (ORCPT ); Mon, 30 Mar 2009 13:08:18 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:43168 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbZC3RIR (ORCPT ); Mon, 30 Mar 2009 13:08:17 -0400 Date: Mon, 30 Mar 2009 09:58:26 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Mark Lord cc: Ric Wheeler , Chris Mason , "Andreas T.Auer" , Alan Cox , Theodore Tso , Stefan Richter , Jeff Garzik , Matthew Garrett , Andrew Morton , David Rees , Jesper Krogh , Linux Kernel Mailing List Subject: Re: Linux 2.6.29 In-Reply-To: <49D0F399.5010407@rtr.ca> Message-ID: References: <49CD7B10.7010601@garzik.org> <49CD891A.7030103@rtr.ca> <49CD9047.4060500@garzik.org> <49CE2633.2000903@s5r6.in-berlin.de> <49CE3186.8090903@garzik.org> <49CE35AE.1080702@s5r6.in-berlin.de> <49CE3F74.6090103@rtr.ca> <20090329231451.GR26138@disturbed> <20090330003948.GA13356@mit.edu> <49D0710A.1030805@ursus.ath.cx> <20090330100546.51907bd2@the-village.bc.nu> <49D0A3D6.4000300@ursus.ath.cx> <49D0AA4A.6020308@redhat.com> <49D0CDBA.7040702@rtr.ca> <49D0D08E.3090100@redhat.com> <49D0DAD3.6030507@rtr.ca> <49D0DDFE.5080701@redhat.com> <49D0E35E.9080003@rtr.ca> <49D0E4E8.20508@redhat.com> <49D0F399.5010407@rtr.ca> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 52 On Mon, 30 Mar 2009, Mark Lord wrote: > > I spent an entire day recently, trying to see if I could significantly fill > up the 32MB cache on a 750GB Hitach SATA drive here. > > With deliberate/random write patterns, big and small, near and far, > I could not fill the drive with anything approaching a full second > of latent write-cache flush time. > > Not even close. Which is a pity, because I really wanted to do some testing > related to a deep write cache. But it just wouldn't happen. > > I tried this again on a 16MB cache of a Seagate drive, no difference. > > Bummer. :) Try it with laptop drives. You might get to a second, or at least hundreds of ms (not counting the spinup delay if it went to sleep, obviously). You probably tested desktop drives (that 750GB Hitachi one is not a low end one, and I assume the Seagate one isn't either). You'll have a much easier time getting long latencies when seeks take tens of ms, and the platter rotates at some pitiful 3600rpm (ok, I guess those drives are hard to find these days - I guess 4200rpm is the norm even for 1.8" laptop harddrives). And also - this is probably obvious to you, but it might not be immediately obvious to everybody - make sure that you do have TCQ going, and at full depth. If the drive supports TCQ (and they all do, these days) it is quite possible that the drive firmware basically limits the write caching to one segment per TCQ entry (or at least to something smallish). Why? Because that really simplifies some of the problem space for the firmware a _lot_ - if you have at least as many segments in your cache as your max TCQ depth, it means that you always have one segment free to be re-used without any physical IO when a new command comes in. And if I were a disk firmware engineer, I'd try my damndest to keep my problem space simple, so I would do exactly that kind of "limit the number of dirty cache segments by the queue size" thing. But I dunno. You may not want to touch those slow laptop drives with a ten-foot pole. It's certainly not my favorite pastime. Linus -- 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/