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?
Regards
Ingo Oeser
-- Science is what we can tell a computer. Art is everything else. --- D.E.Knuth - 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/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:36 EST