Messages in this thread | | | Date | Mon, 10 Feb 2003 21:55:36 +1100 | From | Nick Piggin <> | Subject | Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] |
| |
Andrew Morton wrote:
>Hans Reiser <reiser@namesys.com> wrote: > >>readahead seems to be less effective for non-sequential objects. Or at >>least, you don't get the order of magnitude benefit from doing only one >>seek, you only get the better elevator scheduling from having more >>things in the elevator, which isn't such a big gain. >> >>For the spectators of the thread, one of the things most of us learn >>from experience about readahead is that there has to be something else >>trying to interject seeks into your workload for readahead to make a big >>difference, otherwise a modern disk drive (meaning, not 30 or so years >>old) is going to optimize it for you anyway using its track cache. >> >> > >The biggest place where readahead helps is when there are several files being >read at the same time. Without readahead the disk will seek from one file >to the next after having performed a 4k I/O. With readahead, after performing >a (say) 128k I/O. It really can make a 32x difference. > >Readahead is brute force. The anticipatory scheduler solves this in a >smarter way. > >Yes, device readahead helps. But I believe the caches are only 4-way >segmented or thereabouts, so it is easy to thrash them. Let's test: > [snip results]
> > >Still only 300%. I'd expect to see much larger differences on some older >SCSI disks I have here. > It would be interesting to see numbers with and without anticipatory scheduling as well. I have tried two streaming readers. Speed with default readahead 13MB/s Speed with no readahead, no anticipation 7MB/s Speed with no readahead, anticipation 11.8MB/s
I suspect more readers will simply favour the anticipatory scheduler more.
Nick
- 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/
| |