![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:33 [from the cache] ©2003-2008 | |||||||||||||