On Mon, 2010-02-08 at 09:49 -0800, Josh Berkus wrote:
> FWIW, back when deadline was first introduced Mark Wong did some tests
> and found Deadline to be the fastest of 4 on DBT2 ... but only by about
> 5%. If the read vs. checkpoint analysis is correct, what was happening
> is the penalty for che
da...@lang.hm wrote:
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.
Quick survey just of what's within 20 feet of me:
-Primary desktop: 2 years old, requires 2.6.23 or later for SATA to work
-Server: 3 years ol
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
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.
--
Gr
On Feb 9, 2010, at 10:37 PM, Greg Smith 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 perf
On Feb 10, 2010, at 1:37 AM, Greg Smith 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.
On Tue, Feb 9, 2010 at 11:37 PM, Greg Smith 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
>> p
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
messe
On Feb 8, 2010, at 11:35 PM, da...@lang.hm wrote:
And, yes, the whole I/O scheduling approach in Linux was just
completely redesigned for a very recent kernel update. So even
what we think we know is already obsolete in some respects.
I'd done some testing a while ago on the schedulers
On Mon, 8 Feb 2010, Greg Smith wrote:
Hannu Krosing wrote:
Have you kept trace of what filesystems are in use ?
Almost everything I do on Linux has been with ext3. I had a previous
diversion into VxFS and an upcoming one into XFS that may shed more light on
all this.
it would be nice if
Hannu Krosing wrote:
Have you kept trace of what filesystems are in use ?
Almost everything I do on Linux has been with ext3. I had a previous
diversion into VxFS and an upcoming one into XFS that may shed more
light on all this.
And, yes, the whole I/O scheduling approach in Linux was
Josh Berkus wrote:
FWIW, back when deadline was first introduced Mark Wong did some tests
and found Deadline to be the fastest of 4 on DBT2 ... but only by about
5%. If the read vs. checkpoint analysis is correct, what was happening
is the penalty for checkpoints on deadline was almost wiping ou
On Feb 8, 2010, at 9:49 AM, Josh Berkus wrote:
>
> Those tests were also done on attached storage.
>
> So, what this suggests is:
> reads: deadline > CFQ
> writes: CFQ > deadline
> attached storage: deadline > CFQ
>
From my experience on reads:
Large sequential scans mixed with concurrent r
On Mon, Feb 8, 2010 at 9:49 AM, Josh Berkus wrote:
>
>> That's basically what I've been trying to make clear all along: people
>> should keep an open mind, watch what happens, and not make any
>> assumptions. There's no clear cut preference for one scheduler or the
>> other in all situations. I
On Mon, Feb 8, 2010 at 10:49 AM, Josh Berkus wrote:
>
>> That's basically what I've been trying to make clear all along: people
>> should keep an open mind, watch what happens, and not make any
>> assumptions. There's no clear cut preference for one scheduler or the
>> other in all situations.
> That's basically what I've been trying to make clear all along: people
> should keep an open mind, watch what happens, and not make any
> assumptions. There's no clear cut preference for one scheduler or the
> other in all situations. I've seen CFQ do much better, you and Albe
> report situat
Kevin Grittner wrote:
I'll keep this in mind as something to try if we have problem
performance in line with what that page describes, though
That's basically what I've been trying to make clear all along: people
should keep an open mind, watch what happens, and not make any
assumptio
"Albe Laurenz" wrote:
> Greg Smith wrote:
>> http://insights.oetiker.ch/linux/fsopbench/
>
> That is interesting; particularly since I have made one quite
> different experience in which deadline outperformed CFQ by a
> factor of approximately 4.
I haven't benchmarked it per se, but when we s
Greg Smith wrote:
> Recently I've made a number of unsubstantiated claims that the deadline
> scheduler on Linux does bad things compared to CFQ when running
> real-world mixed I/O database tests. Unfortunately every time I do one
> of these I end up unable to release the results due to client
19 matches
Mail list logo
