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

From: david@lang.hm
Subject: Re: Linux I/O tuning: CFQ vs. deadline
Date: ,
Msg-id: alpine.DEB.2.00.1002101749150.4721@asgard.lang.hm
(view: Whole thread, Raw)
In response to: Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith)
Responses: Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith)
List: pgsql-performance

Tree view

Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
 Re: Linux I/O tuning: CFQ vs. deadline  ("Albe Laurenz", )
  Re: Linux I/O tuning: CFQ vs. deadline  ("Kevin Grittner", )
   Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
    Re: Linux I/O tuning: CFQ vs. deadline  (Josh Berkus, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Marlowe, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Mark Wong, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Carey, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Jeff Davis, )
 Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
  Re: Linux I/O tuning: CFQ vs. deadline  (, )
   Re: Linux I/O tuning: CFQ vs. deadline  (Jeff, )
    Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Marlowe, )
      Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
       Re: Linux I/O tuning: CFQ vs. deadline  (, )
        Re: Linux I/O tuning: CFQ vs. deadline  (Greg Smith, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Jeff, )
     Re: Linux I/O tuning: CFQ vs. deadline  (Scott Carey, )

On Wed, 10 Feb 2010, Greg Smith wrote:

> Scott Marlowe wrote:
>> 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.
>
> I'd be happy just to find fast hardware that works on every kernel from the
> RHEL5 2.6.18 up to the latest one without issues.

it depends on your definition of 'fast hardware'

I have boxes that were very fast at the time that work on all these
kernels, but they wouldn't be considered fast by todays's standards.

remember that there is a point release about every 3 months, 2.6.33 is
about to be released, so this is a 3 x (33-18) = ~45 month old kernel.

hardware progresses a LOT on 4 years.

most of my new hardware has no problems with the old kernels as well, but
once in a while I run into something that doesn't work.

David Lang


pgsql-performance by date:

From: Tom Lane
Date:
Subject: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
From: jesper@krogh.cc
Date:
Subject: Re: perf problem with huge table