Subject: Re: [linux-audio-dev] oh well, so much for mlock/mmap
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 05 2000 - 06:21:33 EEST
>> I wrote two test programs (see below). One of them uses mlock/mmap to
>> step through 24 files, locking their data into RAM in 256kB chunks.
>> The other uses pread(2) to copy data into an mlocked buffer.
>>
>> The mmap/mlock version takes 3 times as long as the pread version.
>
>Did you try doing this without the mlock? Without mlock() you will
>need to read at least a byte from each page.
Yep, been there, done that. The problem with not having mlock is that
some of the read-ahead data can get paged out. Bad news when we come
to copy it into the audio h/w buffer. In fact, more than bad news -
it causes a drop out.
>What kind of disks are you using? Its my understanding that IDE
>don't work all that well.
Ultra2 SCSI, 80MB/sec, 5.2 and 7.5 and 4.5ms seek times.
On my fast wide SCSI disks in an experiment
>similar to yours, I was able to do the read data from 32 files of
>48 Meg each. By mmapping the files in 256k chunks, I was able to
>"read" the files at what would have been a rate to 400k samples
>per second on 24 bit samples. This is on fast wide SCSI with 2 450MHz
>PII processors). The data rate off the disks was about 37Meg/sec
>(over 40 sec) which is very close to the limit of the IBM disk I
>am using. Using read the data rate dropped to about 10Meg/sec.
OK, I'll try some variations on the experiment to see if I can get
close to this. But keep in mind that data rates are not the only
bottom line here - seek+read times are key. Still, if you could get
this performance, then there must be some variation on what happens in
my test cases that could help.
--p
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 05:53:45 EEST