Messages in this thread |  | | Date | Mon, 10 Feb 2003 18:41:14 +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 03:58:26PM +1100, Nick Piggin wrote: > >>Jakob Oestergaard wrote: >> >> >>>On Sun, Feb 09, 2003 at 08:33:43PM -0800, Andrew Morton wrote: >>> >>> >>>>David Lang <david.lang@digitalinsight.com> wrote: >>>> >>>> >>>>>note that issuing a fsync should change all pending writes to >>>>>'syncronous' >>>>>as should writes to any partition mounted with the sync option, or writes >>>>>to a directory with the S flag set. >>>>> >>>>> >>>>We know, at I/O submission time, whether a write is to be waited upon. >>>>That's in writeback_control.sync_mode. >>>> >>>>That, combined with an assumption that "all reads are synchronous" would >>>>allow the outgoing BIOs to be appropriately tagged. >>>> >>>> >>>This may be a terribly stupid question, if so pls. just tell me :) >>> >>>I assume read-ahead requests go elsewhere? Or do we assume that someone >>>is waiting for them as well? >>> >>>If we assume they are synchronous, that would be rather unfair >>>especially on multi-user systems - and the 90% accuracy that Rik >>>suggested would seem exaggerated to say the least (accuracy would be >>>more like 10% on a good day). >>> >>> >>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. >> > >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.
- 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/
|  |