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)
I must say it works quite well, and firing up apps, or accessing the KDE menus,
is faster,
launching my famous "xterm" still produces disk accesses,
(cached files are still trown away after a while, but not so agressively like
in the read() case )
but it's now faster and the system seems more usable,
especially painting into a GIMP window, since gimp uses the hd quite a lot.
I'm now able to stream about 50 mono audio tracks (44kHz 16bit) from my
IBM 16GB EIDE UDMA disk, while browsing the web, very fun !
Of course if I copy a large file in background, sooner of later, I get a
ring-buffer overrun , because the streaming-app and the cp must share disk
bandwidth. ( I'm missing SGI's guaranteed rate I/O of XFS , sigh .. :-) )
again , thank you for your suggestion !
It was a bit tricky to mess with all this page aligns, and special cases,
but it pretty fun to code ! ( got nice segfaults at the beginning :-) )
>
> in short, cache flushing is well-understood and media production is just
> one minor case where it comes up. hinting (via O_ flags, madvise, ioctl)
> are the right way to turn up the agressiveness of the existing free-behind
> and pre-fetching mechanisms.
Does anyone know if there it/will be a way to do unbuffered mmap() ?
I think streaming apps would benefit quite a bit from this.
>
> regards, mark hahn.
regards,
Benno.
-
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/