I discovered that using mmap() you can achieve better performance for
multitrack HD playback ( 50 tracks of 80kb/sec each) than using regular read()
calls.
The way I'm doing it is to mmap() / munmap() portions of the file into
userspace.
The reason of the performance boost might be the avoiding of read-aheads,
which would be discarded becasue there is a lot of disk seeking activity.
OF course for reliable realtime multimedia we need mlockall().
But mmapping() a long file into mem would cause all the pages to be transferred
into mem, therefore eliminating the mmap() advantage.
my proposal would be a linux-specific MAP_ flag,
MAP_UNLOCKED which would cause mmap() NOT to do page-ins for the entire
mmaped area, when MCL_FUTURE is set.
Actually you can solve the problem by using multipe threads:
let the thread which does the mmap() run without MCL_FUTURE, communicate
with the MCL_CURRENT|MCL_FUTURE mlocked() thread (which drives the audio
interface).
But as stated above you need 2 threads.
I think it wouldn't be hard to add a MAP_UNLOCKED flag to the mmap() kernel
code.
would it be enough to modify the VM_LOCKED check in mm/mmap.c in : ?
or are there other places where you must touch code ?
if (flags & VM_LOCKED && !(flags & MAP_UNLOCKED)) {
mm->locked_vm += len >> PAGE_SHIFT;
make_pages_present(addr, addr + len);
}
this would be beneficial for streaming apps under low-memory conditions.
like for terminatorX (http://termx.cjb.net) where you can scratch (dj-like)
big WAV files.
MCL_FUTURE + MAP_UNLOCK would be ideal since on a low-mem box
I can't mmap() a 100MB file into 8MB RAM using mlockall(MCL_FUTURE).
I know that it's a bit a contraddiction MCL_FUTURE + non-memory locked mmap()
plus it is non standard, but with this approach when there is swapping in
progress, at least you shared libs stay mlocked() into mem.
any thoughts ?
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/