AStreamRefillStream poor performance over NFS on MacOS

[pgdh]

Hi, I've been using VLC for some time, but often have had difficulty playing HD 1080 streams over NFS to my Mac. Today, I did some investigations with DTrace on the Mac client and OpenSolaris server, and discovered that the Mac was sometimes pulling 20x the required amount of data. This is because the default NFSv3 read size for TCP is 32K, because the MacOS NFS client has no read cache, and because VLC was issuing 1786 byte reads. This means each 32K block is read about 20 times.

The stack trace for this I/O looks like this ...

libsystem_kernel.dylib`read+0xa
libvlccore.4.dylib`AReadStream+0x66
libvlccore.4.dylib`AStreamRefillStream+0xce
libvlccore.4.dylib`AStreamReadNoSeekStream+0x150
libstream_filter_record_plugin.dylib`Read+0x4b
libvlccore.4.dylib`stream_Block+0x2e
libts_plugin.dylib`Demux+0x70a
libvlccore.4.dylib`MainLoop+0x1d3
libvlccore.4.dylib`Run+0x31
libvlccore.4.dylib`thread_entry+0x3e
libsystem_c.dylib`_pthread_start+0x14f
libsystem_c.dylib`thread_start+0xd

I had a quick look at the code for AStreamRefillStream and noticed that i_read is variable. I just don't know the code well enough to know what is going on. Sometimes it is ok (i.e. I get large reads all the time). Other times, it starts off ok, and then jumps to smaller reads. But once it is using small reads, it doesn't seem to go back to large ones. The file I was reads was about 6GB in size. I'm just hoping this will ring a bell with someone who knows the code well.

[Jean-Baptiste Kempf]

Try to increase file-caching then

[pgdh]

The amount of file cache is not the issue. 300ms at 1.8MB/sec is over 500K. The issue is that the AStreamRefillStream function starts reading in small chunks, and never goes back to reading larger chunks. A quick look at the code makes me wonder if there's a bug - e.g. around the use of i_read, i_toread, i_used etc ... there's also quite a few TODOs in the code related to these.

I am puzzled that the moderator moved my question from the contributors category to here, because I think this is primarily an issue of source code inefficiency. To my simple mind it would seem that a static 6GB file should be read in fairly large chunks.

[pgdh]

Ok, here's some more data. The read sizes are unpredictable, generally start small, but can become large if I seek forward or back in the file. I'm using a simple DTrace one-liner to count the number of times read(2) is called with a particular buffer size per second. A blank line is inserted every second.

bash-3.2# dtrace -qn 'syscall::read:entry /execname == "VLC"/ {@[arg2] = count();} tick-1s {printa(@); trunc(@);}'

3 1
85 1
1024 1
6984 1
8096 298

// this means we saw read(x, y, 8096) happen 298 times in the first second

8096 154

// this means we saw read(x, y, 8096) happen 154 times in the second second

576 1
7520 1
8096 187

8096 204

1152 1
6944 1
8096 222

8096 287

1728 1
6368 1
8096 306

8096 329

2304 1
5792 1
8096 322

8096 243

// at this point, I seeked forward 5-6 minutes into the video

42891 1
563717 1
1722346 1
1765320 1
3016151 1

// notice that we are now doing nice big efficient reads

242575 1
383544 1
626123 1
626119 3

626119 3

626119 2

195015 1
431104 1
626119 1

626119 3

626119 2

6486 1
619633 1
626119 2

// and this is where I seeked back to the beginning

2754 1
104742 1
202916 1
205705 1
626119 1
1827627 1
104569 3
205670 12

1485573 1
104569 20
25565 58

259612 1
1225961 1

1485573 1

1485573 1

522027 1
963546 1

1485573 2

701131 1
784442 1

// and this is where I stopped the test
^C

bash-3.2#

The actual read sizes seem to change from run to run. When I did my test yesterday, VLC was issuing 1786 byte reads at steady state, playing from the start of another 6GB HD 1080 video.

The new thing for me today is that seeking (with the mouse on the video playback window progress indicator), seems to toggle VLC into reading bigger sizes. But there seems no way to get a predictable size.

It is also very interesting that VLC will start reading the file with small reads, but when I seek back to the beginning, to the same region of the file, it uses large reads to re-read the same data.

[pgdh]

I have a workaround which is to use mmap(2) instead of read(2) via Preferences -> Input / Codecs -> Access modules -> Mmap.

However, the drawback with the Mmap implementation is that it pollutes the page cache (increasing what Activity Monitor calls "Inactive" memory, and reducing "Free").

VLC doesn't mmap() the whole file in one go (although this would be done with a 64-bit version), but calls mmap(2) and munmap(2) to large blocks.

DTrace reveals a call to madvise(,,MADV_SEQUENTIAL) from within AReadBlock (in modules/access/mmap.c). I wonder if an explicit call to madvise(,,MADV_FREE) just before munmap(2) would fix the cache polution?