Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
Andrea Arcangeli (email@example.com)
Mon, 10 Feb 2003 08:36:14 +0100
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 <firstname.lastname@example.org> wrote:
> >>>note that issuing a fsync should change all pending writes to
> >>>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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/