mmap() works until you have a file that is larger than you can specify as an
offset to mmap(). After a few minutes of uncompressed video, mmap() runs
out of address bits.
For no rational technical reason, I'd prefer a solution that uses no data
buffering in the kernel at all (file metadata is OK, but no data blocks
in the cache). In this case read-ahead can be done in user-space by a number
of I/O threads generating interleaved, efficiently-sized read requests.
In effect, this is user-space simulation of asynchronous I/O.
Real asynchronous I/O with no buffering in the kernel would allow all
of the I/O parts of the multimedia application to be done in one thread,
if desired. No read-ahead is required in the kernel in that case since
the reader can hand the kernel a list of consecutive read requests to
satisfy.
-- Zygo Blaxell, Linux Engineer, Corel Corporation. zygob@corel.ca (work) or zblaxell@furryterror.org (play). Opinions above are my own, not Corel's.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/