correct, that's the huge improvement I get in the read sequential case
(i.e. bonnie), which is a crucial common workload.
> SCSI, but it is very interesting that writes don't get a noticable
> improvement although they would be using the bigger request sizes
> too, right? Something is causing this but the cpu, bus, wire
It's the readahead in my tree that allows the reads to use the max scsi
command size. It has nothing to do with the max scsi command size
writes don't need readahead to use the max command size, they always
used it since the first place, so they can't go even faster, they never
had a problem.
It's by fixing readahead that reads gets boosted. this has nothing to do
with writes or the max_sectors itself.
You can wait 10 minutes and still such command can't grow. This is why
claiming anticipatory scheduling can decrease the need for readahead
doesn't make much sense to me, there are important things you just can't
achieve by only waiting.
> overhead of using small requests does not seem to be it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/