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.
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 |