Re: Linux I/O tuning: CFQ vs. deadline

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jeff <threshar(at)torgo(dot)978(dot)org>, david(at)lang(dot)hm, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Subject: Re: Linux I/O tuning: CFQ vs. deadline
Date: 2010-02-10 07:11:30
Message-ID: dcc563d11002092311od97926fm7e69826995e9ccd0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Feb 9, 2010 at 11:37 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Jeff wrote:
>>
>> I'd done some testing a while ago on the schedulers and at the time
>> deadline or noop smashed cfq.  Now, it is 100% possible since then that
>> they've made vast improvements to cfq and or the VM to get better or similar
>> performance.  I 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?  The mixed
> 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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bryce Nesbitt 2010-02-10 08:29:53 Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Previous Message Greg Smith 2010-02-10 06:37:04 Re: Linux I/O tuning: CFQ vs. deadline