Messages in this thread | | | Date | Wed, 8 Dec 2004 14:48:11 +0100 | From | Jens Axboe <> | Subject | Re: Time sliced CFQ io scheduler |
| |
On Wed, Dec 08 2004, Nick Piggin wrote: > On Wed, 2004-12-08 at 07:58 +0100, Jens Axboe wrote: > > On Wed, Dec 08 2004, Nick Piggin wrote: > > > On Tue, 2004-12-07 at 18:25 -0800, Andrew Morton wrote: > > > > I think we could detect when a disk asks for more than, say, 4 > > > concurrent requests, and in that case turn off read anticipation > > > and all the anti-starvation for TCQ by default (with the option > > > to force it back on). > > > > CFQ only allows a certain depth a the hardware level, you can control > > that. I don't think you should drop the AS behaviour in that case, you > > should look at when the last request comes in and what type it is. > > > > With time sliced cfq I'm seeing some silly SCSI disk behaviour as well, > > it gets harder to get good read bandwidth as the disk is trying pretty > > hard to starve me. Maybe killing write back caching would help, I'll > > have to try. > > > > I "fixed" this in AS. It gets (or got, last time we checked, many months > ago) pretty good read latency even with a big write and a very large > tag depth.
This problem was also caused by the dispatch sort bug. So you were right, it was 'some little bug' in the code :)
-- Jens Axboe
- 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/
| |