Messages in this thread |  | | Date | Mon, 10 Feb 2003 19:27:51 +1100 | From | Nick Piggin <> | Subject | Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] |
| |
Andrea Arcangeli wrote:
>On Mon, Feb 10, 2003 at 06:41:14PM +1100, Nick Piggin wrote: > >>Andrea Arcangeli wrote: >> >> >>>On Mon, Feb 10, 2003 at 03:58:26PM +1100, Nick Piggin wrote: >>> >>>>Remember that readahead gets scaled down quickly if it isn't >>>>getting hits. It is also likely to be sequential and in the >>>>track buffer, so it is a small cost. >>>> >>>>Huge readahead is a problem however anticipatory scheduling >>>>will hopefully allow good throughput for multiple read streams >>>>without requiring much readahead. >>>> What I mean by this is: if we have >1 sequential readers (eg. ftp server), lets say 30MB/s disk, 4ms avg seek+settle+blah time, submitting reads in say 128KB chunks alternating between streams will cut throughput in half... At 1MB readahead we're at 89% throughput. At 2MB, 94%
With anticipatory scheduling, we can give each stream say 100ms so thats 96% with, say... 8K readahead if you like. (Yes, I am aware that CPU/PCI/IDE efficiency also mandates a larger request size).
Anyway that is the theory. It remains to be seen if we can make it work.
>>>> >>>> >>>the main purpose of readahead is to generate 512k scsi commands when you >>>read a file with a 4k user buffer, anticipatory scheduling isn't very >>>related to readahead. >>> >>> >>You seem to be forgetting things like seek time. >> > >I didn't say it's the only purpose. Of course there's no hope for >merging in the metadata dependent reads of the fs where anticipatory >scheduling does its best, and infact they don't even attempt to do any >readhaead. BTW, one thing that should definitely do readhaead and it's >not doing that (at least in 2.4) is the readdir path, again to generate >big commands, no matter the seeks. It was lost with the directory in >pagecache. > >Andrea > > > >
- 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/
|  |