On Mon, Jun 25, 2007 at 11:18:41AM -0400, Lennart Sorensen wrote:
> How do you know 165MB/s is correct?
It is the maximum value I measure. It's also the value that I
measure consistently with NCQ off, like with 2.6.18. Finally,
even before I bought this PC, I did some research and the RAID
with
On Sat, Jun 23, 2007 at 04:59:06AM +0200, Carlo Wood wrote:
> Just one kernel version? The problem here is in every
> kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f
>
> 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5
>
> noop:
> Timing buffered disk reads:
On Sat, Jun 23, 2007 at 04:59:06AM +0200, Carlo Wood wrote:
Just one kernel version? The problem here is in every
kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f
2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5
noop:
Timing buffered disk reads: 254 MB
On Mon, Jun 25, 2007 at 11:18:41AM -0400, Lennart Sorensen wrote:
How do you know 165MB/s is correct?
It is the maximum value I measure. It's also the value that I
measure consistently with NCQ off, like with 2.6.18. Finally,
even before I bought this PC, I did some research and the RAID
with
Andrew Morton wrote:
Please see http://bugzilla.kernel.org/show_bug.cgi?id=8636
In that report a pretty large slowdown with CFQ has been identified.
Jens has plunked a patch in there (Comment #50) and then ran away on
vacation.
If someone can test that patch and demonstrate its goodness, I'll
On Sat, 23 Jun 2007 04:59:06 +0200 Carlo Wood <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote:
> > for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i
> > was:" ; cat $i ; echo anticipatory > $i ; done
> >
> > Should
On Sat, 23 Jun 2007 04:59:06 +0200 Carlo Wood [EMAIL PROTECTED] wrote:
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote:
for i in /sys/block/sd*/queue/scheduler ; do echo -n scheduler for $i
was: ; cat $i ; echo anticipatory $i ; done
Should show you the
Andrew Morton wrote:
Please see http://bugzilla.kernel.org/show_bug.cgi?id=8636
In that report a pretty large slowdown with CFQ has been identified.
Jens has plunked a patch in there (Comment #50) and then ran away on
vacation.
If someone can test that patch and demonstrate its goodness, I'll
Carlo Wood wrote:
> Just one kernel version? The problem here is in every
> kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f
>
> 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5
>
> noop:
> Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec
>
>
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote:
> for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i was:"
> ; cat $i ; echo anticipatory > $i ; done
>
> Should show you the scheduler for all libata/scsi discs, and switch to
> anticipatory. It
Hi Carlo!
On Fri, 22 Jun 2007, Carlo Wood wrote:
> On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 22 Jun 2007, Carlo Wood wrote:
> > > So far I found out that it's RAID only.
> >
> > If you change the IO schedulers, does it help?
>
> How do I do that?
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 22 Jun 2007, Carlo Wood wrote:
> > So far I found out that it's RAID only.
>
> If you change the IO schedulers, does it help?
How do I do that?
--
Carlo Wood <[EMAIL PROTECTED]>
-
To unsubscribe from this
On Fri, 22 Jun 2007, Carlo Wood wrote:
> So far I found out that it's RAID only.
If you change the IO schedulers, does it help?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie."
On Wed, Jun 20, 2007 at 08:36:52PM -0700, Arjan van de Ven wrote:
> also do a
>
> echo 60 > /proc/sys/vm/dirty_ratio
>
> first to see if that helps
That makes no difference.
It took a while before I replied - because I first want to do a bisect
to find a version closer to the problem.
So far
On Wed, Jun 20, 2007 at 08:36:52PM -0700, Arjan van de Ven wrote:
also do a
echo 60 /proc/sys/vm/dirty_ratio
first to see if that helps
That makes no difference.
It took a while before I replied - because I first want to do a bisect
to find a version closer to the problem.
So far I
On Fri, 22 Jun 2007, Carlo Wood wrote:
So far I found out that it's RAID only.
If you change the IO schedulers, does it help?
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. --
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 22 Jun 2007, Carlo Wood wrote:
So far I found out that it's RAID only.
If you change the IO schedulers, does it help?
How do I do that?
--
Carlo Wood [EMAIL PROTECTED]
-
To unsubscribe from this list:
Hi Carlo!
On Fri, 22 Jun 2007, Carlo Wood wrote:
On Fri, Jun 22, 2007 at 06:17:46PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 22 Jun 2007, Carlo Wood wrote:
So far I found out that it's RAID only.
If you change the IO schedulers, does it help?
How do I do that?
for i in
On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote:
for i in /sys/block/sd*/queue/scheduler ; do echo -n scheduler for $i was:
; cat $i ; echo anticipatory $i ; done
Should show you the scheduler for all libata/scsi discs, and switch to
anticipatory. It probably
Carlo Wood wrote:
Just one kernel version? The problem here is in every
kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f
2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5
noop:
Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec
On Wed, 2007-06-20 at 19:06 -0400, Jeff Garzik wrote:
> Carlo Wood wrote:
> > hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
> > on 2.6.18, as expected.
> >
> > In 2.6.22-rc5 this dropped to only 60 MB/s !
> >
> > Is this a known issue?
> >
> > I also measured it with
Carlo Wood wrote:
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
on 2.6.18, as expected.
In 2.6.22-rc5 this dropped to only 60 MB/s !
Is this a known issue?
I also measured it with bonnie; I get 108 MB/s reading speed on
2.6.18 and only 68 MB/s on 2.6.22-rc5.
More info
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
on 2.6.18, as expected.
In 2.6.22-rc5 this dropped to only 60 MB/s !
Is this a known issue?
I also measured it with bonnie; I get 108 MB/s reading speed on
2.6.18 and only 68 MB/s on 2.6.22-rc5.
--
Carlo Wood <[EMAIL
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
on 2.6.18, as expected.
In 2.6.22-rc5 this dropped to only 60 MB/s !
Is this a known issue?
I also measured it with bonnie; I get 108 MB/s reading speed on
2.6.18 and only 68 MB/s on 2.6.22-rc5.
--
Carlo Wood [EMAIL PROTECTED]
Carlo Wood wrote:
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
on 2.6.18, as expected.
In 2.6.22-rc5 this dropped to only 60 MB/s !
Is this a known issue?
I also measured it with bonnie; I get 108 MB/s reading speed on
2.6.18 and only 68 MB/s on 2.6.22-rc5.
More info
On Wed, 2007-06-20 at 19:06 -0400, Jeff Garzik wrote:
Carlo Wood wrote:
hdparm -tT gives over 160 MB/s for my tripple 10k rpm Raptor RAID5
on 2.6.18, as expected.
In 2.6.22-rc5 this dropped to only 60 MB/s !
Is this a known issue?
I also measured it with bonnie; I get 108 MB/s
26 matches
Mail list logo
