DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=etwIDf44eFEsFcCFVOcQKP3++1zh6Vom3j0NzoU/6OTbq+8ae0jyp+bd2YduNYx5Fl
	afRIciQY0RttgItqAZJ5VUzWVjfByt8vI6Z6t1dhgTc/RQ7O3oVMPn7gXBWskqfh0UWl
	GCvlSBBYyfTeKfZlaAghuH6JQa6qO1BAfldrA=
MIME-Version: 1.0
In-Reply-To: <4B725410.5010000@2ndquadrant.com>
References: <4B6FDD26.9010106@2ndquadrant.com>
	<D960CB61B694CF459DCFB4B0128514C203938157@exadv11.host.magwien.gv.at>
	<4B6FD868020000250002F084@gw.wicourts.gov>
	<4B702E05.1000708@2ndquadrant.com> <1265652529.2153.13.camel@hvost>
	<4B70E18D.2040709@2ndquadrant.com>
	<alpine.DEB.2.00.1002082033090.6976@asgard.lang.hm>
	<39DDB34B-C375-46ED-83D2-688A32188100@torgo.978.org>
	<4B725410.5010000@2ndquadrant.com>
Date: Wed, 10 Feb 2010 00:11:30 -0700
Message-ID: <dcc563d11002092311od97926fm7e69826995e9ccd0@mail.gmail.com>
Subject: Re: Linux I/O tuning: CFQ vs. deadline
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Jeff <threshar@torgo.978.org>, david@lang.hm,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org, Albe Laurenz <laurenz.albe@wien.gv.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 9, 2010 at 11:37 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Jeff wrote:
>>
>> I'd done some testing a while ago on the schedulers and at the time
>> deadline or noop smashed cfq. =A0Now, it is 100% possible since then tha=
t
>> they've made vast improvements to cfq and or the VM to get better or sim=
ilar
>> performance. =A0I recall a vintage of 2.6 where they severely messed up =
the
>> VM. Glad I didn't upgrade to that one :)
>>
>> Here's the old post:
>> http://archives.postgresql.org/pgsql-performance/2008-04/msg00155.php
>
> pgiosim doesn't really mix writes into there though, does it? =A0The mixe=
d
> read/write situations are the ones where the scheduler stuff gets messy.

I agree. I think the only way to really test it is by testing it
against the system it's got to run under.  I'd love to see someone do
a comparison of early to mid 2.6 kernels (2.6.18 like RHEL5) to very
up to date 2.6 kernels.  On fast hardware.  What it does on a laptop
isn't that interesting and I don't have a big machine idle to test it
on.