[MPlayer-dev-eng] [PATCH] Use posix_fadvise in stream_file if available

[Tobias Diedrich]

Updated version.
I removed the two posix_fadvise calls in open and seek, since for
both cases a delay is to be expected anyway, having fadvise just in
fill_buffer should be enough.

Benchmark:
IO bound actions like stream copy or dumpstream are candidates for
negative effects due to extra syscall overhead, so:

dumpvideo with patch:
Run1: 1m37.205s real, 1m20.357s system, 0m2.746s user
Run2: 1m31.223s real, 1m19.923s system, 0m2.726s user
This one is actually CPU-bound on this system.

dumpvideo without patch:
Run1: 0m54.749s real, 0m7.221s system, 0m4.676s user
Run2: 0m55.752s real, 0m7.122s system, 0m4.811s user
IO-bound

So, the "don't call fadvise every time with the whole 1MB area" I
had in it at first was not premature.
Let's try a slightly modified patch that looks ahead PREFETCH_LEN
and uses max_len for the length...
(Still suboptimal, since max_len is usually 2048 and posix_fadv is
bound to use full pages internally...)

dumpvideo with modified patch:
Run1: 0m52.384s real, 0m7.364s system, 0m4.016s user
Run2: 0m53.041s real, 0m7.408s system, 0m3.986s user
IO-bound, slight speedup?

Much better, but needs the fadvise calls in open and seek added back
in. Let's try calling fadvise only occasionally instead.
dumpvideo with third patch:
Run1: 0m54.417s real, 0m11.211s system, 0m2.980s user
Run2: 0m51.495s real, 0m11.067s system, 0m2.914s user
IO-bound

Hmm, increased the amount spent in kernel, let's go back to the
previous version and add the fadvise calls in open and seek.
Run1: 0m53.896s real, 0m11.641s system, 0m3.220s user
Run2: 0m52.512s real, 0m11.658s system, 0m3.216s user

*strace run*
Ok, looks like the file I used for testing is one of those badly
muxed ones, the demuxer seeks a lot (would be nice if it could skip
audio completely for -dumpvideo) so quite a few overlapping fadvises
for the whole 1MB prefetch get called explaining the increased
system time.
Unfortunately a lot of Leopard-Raws files are broken that way...

Trying a properly mixed file:

Unpatched:
Run1: 0m52.213s real, 0m4.361s system, 0m2.019s user
Run2: 0m51.481s real, 0m4.258s system, 0m2.093s user

Patched:
Run1: 0m48.986s real, 0m4.970s system, 0m2.056s user
Run2: 0m48.376s real, 0m5.005s system, 0m1.975s user

Yep, that looks more reasonable.

Updated patch attached.

-- 
Tobias						PGP: http://8ef7ddba.uguu.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fadvise.alt.patch
Type: text/x-diff
Size: 1666 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20091109/49798dcb/attachment.patch>