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 scheduler for all libata/scsi discs, and switch to > > anticipatory. It probably works for hd* as well, but I don't have any > > around to test. > > > > I had ridiculous md raid performance (on resync) using cfq at least once. > > Unfortunately I never bothered trying to track it down, and I didn't check > > the throughput after the resync was done either. Also, I don't recall the > > kernel version, but it was either 2.6.18 or 2.6.20. > > 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 > > anticipatory: > Timing buffered disk reads: 252 MB in 3.02 seconds = 83.43 MB/sec > > deadline: > Timing buffered disk reads: 258 MB in 3.02 seconds = 85.41 MB/sec > > cfq: > Timing buffered disk reads: 194 MB in 3.03 seconds = 64.06 MB/sec > > The normal value is cfq. So, all other schedulars are somewhat faster, > but still far from the correct 165 MB/s. > 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 queue it up, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
