Subject: Re: [linux-audio-dev] munlock and mmap
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Apr 05 2000 - 00:11:46 EEST
Had you looked better at my code I sent you (the famous
lockfree ringbuffer), then you wouldn't have these problems now.
:-)
the best strategy is, as you mentioned
use mlockall() , and then mmap() the piece of the file you need into mem
at the right location in the ringbuffer.
When the data area isn't needed anymore, just munmap() it.
mlockall() automatically causes mmap() to load all pages into mem,
without being forced to access them. (see old linux-kernel postings)
With this trick you don't risk running out of virtual mem address space,
since you mmap() only parts of the file.
For example if you have 26 files of 1GB each, you are unable to mmap()
all the files simultaneously into mem due to the fact that the x86 has only
4GB (2GB) of address space.
With the mmap() / munmap() trick the limit is only the disk space, and the
max filesize of ext2 ( 2GB).
PS: of course it works without XFS, RAW IO etc, or I wouldn't be able
to play 60 tracks on my 16GB IBM EIDE disk.
:-)
Benno.
On Tue, 04 Apr 2000, Paul Barton-Davis wrote:
> yeah, now i *really* understand why i did this.
>
> i wanted to map the file once, so that the audio thread and butler
> thread never had any races over the current VM location of the mmap
> buffer.
>
> if i have to munmap() the track file in pieces so that i can tell the
> kernel that i don't care about sections of memory anymore, it means
> that i can't have a single location where the mmap buffer can always
> be found.
>
> this starts to get hairy again.
>
> needless to say, i am determined to make this work without XFS, raw
> I/O or anything else, just so that when those things become
> compelling, it all works even better. sigh.
>
> --p
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 01:13:59 EEST