Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]

David Lang
2003-02-10T04:10:41Z

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.

David Lang

On Mon, 10 Feb 2003, Rik van Riel
wrote:

> Date: Mon, 10 Feb 2003 02:15:10 -0200 (BRST)
> From: Rik van Riel <riel@conectiva.com.br>
> To: Andrea Arcangeli <andrea@suse.de>
> Cc: Con Kolivas <ckolivas@yahoo.com.au>, lkml <linux-kernel@vger.kernel.org>,
> Jens Axboe <axboe@suse.de>
> Subject: Re: stochastic fair queueing in the elevator [Re: [BENCHMARK]
> 2.4.20-ck3 / aa / rmap with contest]
>
> On Mon, 10 Feb 2003, Rik van Riel wrote:
>
> > The only aspect of the anticipatory scheduler that is no longer needed
> > with your SFQ idea is the distinction between reads and writes, since
> > your idea already makes the (better, I guess) distinction between
> > synchronous and asynchronous requests.
>
> Forget that I said that, we don't have the infrastructure to
> get this right. The definition of "synchronous" is "some
> process is waiting on this request to complete", but processes
> wait on other objects instead.
>
> A normal sequence (probably the most common) is:
>
> 1) submit request
> (request is now asynchronous)
> 2) wait_on_page
> (request should now magically become synchronous)
>
> The infrastructure to get this working is probably too big a
> change for 2.5/2.6, at this point, so chances are that we're
> better off using the (90% accurate?) distinction between reads
> and writes.
>
> regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
> http://www.surriel.com/ http://guru.conectiva.com/
> Current spamtrap: october@surriel.com
> -
> 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/
>