Messages in this thread | | | From | (Zygo Blaxell) | Subject | Re: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and makes Linux unusable | Date | 26 Aug 1999 13:39:04 -0400 |
| |
In article <99082518171300.02559@linuxhost.localdomain>, Benno Senoner <sbenno@gardena.net> wrote: >I adapted my file streaming app to use mmap() instead of using read() to read >chunks of up to 512k into a buffer. >As you suggested I do basically the following: >- ptr=mmap() at current offset with len=512k >- memcpy(targetbuffer,ptr,len) (I must use the memcpy since targetbuffer has >to be mlocked() since the audio-playing thread can't tolerate pagefaults >because it runs in a low-latency cycle. >- munmap(ptr,len)
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/
| |