> Linus and I talked about this - we were thinking about adding a
>
> reada(fd, offset, len)
>
> interface which says fetch len bytes into the buffer cache at the offset
> on that fd.
>
> We were also thinking about adding a hack to select such that you could do
>
> reada(fd, offset, len);
>
> /* other work */
>
> select(...fd..., ...)
>
> to block until the reada has completed. Why bother when you could just block
> in the read? Because you might do several reada()'s on several different
> fd's.
>
> One limitation of this approach is that the select can only inform you
> about one of potentially many reada() requests. We didn't know what to do
> about that.
(hope i got it right), we want to start several read requests, but we have
absolutely no status information. Normal Unix semantics give one
possibility:
- read informs about >one< operation, but we dont know which one will
finish first.
with the select hack you mentioned, this picture gets a bit extended:
- select informs about the >first< request that finishes, but doesnt give
information about the status of other requests.
( and if you select() without a timeout, then the task might just sleep
forewer of the readahead gets trashed by other requests?? )
If my approach is correct, then the next extension would be to introduce
status information and/or request priorities. Failed/urgent requests (a
failed request gets more urgent) could get increased priority. The
decision is in user space. If a http or nfs request doesnt finish in time,
then it gets a bit more priority (ie. user space calls a system call to
get increased priority for a request or extending the readahead call by
a priority or whatever).
Note that we miss process priorities here. What we need is asyncron IO,
but the problems you mention need distinction between requests. (which is
done automatically if the requests are issued from different processes).
am i way off?
-- regards, Ingo Molnar