That's OK - you're already doing -rmap. I just can't read.
> ...
> > If the IO load was against the same disk 2.5 _should_ have sucked,
> > due to the writes-starves-reads problem which we're working on. So
> > I assume it was against a different disk. In which case 2.5 should not
> > have shown these improvements, because all the fixes for this are still
> > in -mm. hm. Helpful, aren't I?
>
> It's the same disk. These are the correct values after I've fixed all known
> problems in contest. I need someone else to try contest with a different disk.
> Helpful? This is all new so it will take a while for _anyone_ to understand
> exactly what's going on I'm sure. Since we haven't had incremental benchmarks
> till now, who knows what it was that made IO full mem drop from 146 to 74 in the
> first place?
Strange. 2.5 should have done badly. There are many variables...
We're on top of the VM latency problems now. Jens is moving ahead
with the deadline scheduler which appears to provide nice linear
tunability of the read-versus-write policy. Once we sort out the
accidental writes-starve-read problem we'll do well at this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/