Re: [ak@suse.de: Re: iosched: impact of streaming read on read-many-files]

[Andrea Arcangeli <andrea@suse.de>]

On Sat, Feb 22, 2003 at 02:57:28PM +0100, Ingo Oeser wrote:
> On Fri, Feb 21, 2003 at 11:07:16PM -0800, Andrew Morton wrote:
> > You have not defined "fix".  An IO scheduler which attempts to serve every
> > request within ten milliseconds is an impossibility.  Attempting to 
> > achieve it will result in something which seeks all over the place.
> > 
> > The best solution is to implement five or ten seconds worth of buffering
> > in the application and for the kernel to implement a high throughput general
> > purpose I/O scheduler which does not suffer from starvation.
> 
> What about implementing io-requests, which can time out? So if it will
> not be serviced in time or we know, that it will not be serviced
> in time, we can skip that.
> 
> This can easily be stuffed into the aio-api by cancelling
> requests, which are older than a specified time. Just attach a
> jiffie to each request and make a new syscall like io_cancel but
> with a starting time attached. Or even make it a property of the
> aio list we are currently handling and use a kernel timer.
> 
> That way we could help streaming applications and the kernel
> itself (by reducing its io-requests) at the same time.
> 
> Combined with you buffering suggestion, this will help cases,
> where the system is under high load and cannot satisfy these
> applications anyway.
> 
> What do you think?

that works only if the congestion cames from multimedia apps that are
willing to cancel the timed out (now worthless) I/O, that is never the
case normally due the low I/O load they generate (usually it's apps not
going to cancel the I/O that congest the blkdev layer).

still, it's a good idea, you're basically asking to implement the cancel
aio api and I doubt anybody could disagree with that ;).

Andrea