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

Tobias Diedrich ranma at tdiedrich.de
Tue Nov 10 04:50:00 CET 2009


Reimar Döffinger wrote:
> On Mon, Nov 09, 2009 at 07:02:36PM +0100, Tobias Diedrich wrote:
> > Tobias Diedrich wrote:
> > > > Playing something from a slow disk/device while also decoding
> > > > might give something useful (sshfs over wireless maybe?).
> > > 
> > > I doubt it, since it does not cause more IO to take place than
> > > before (vmstat does not show an increased read io rate, the kernel
> > > checks for already mapped pages) and in the decoding case only a
> > > miniscule amount of time will be spent on the IO.
> > 
> > FWIW:
> > ~280ms ping, 10000Km between server and client, playing from sshfs.
> > Server pipe 100Mbit, client pipe FTTH, throughput in this test about
> > 600KB/s
> > SDTV file this time.
> > mplayer -noquiet -nosound -benchmark -frames 2000 -vo null
> > 
> > Without patch:
> > Run1:
> > BENCHMARKs: VC:   7.286s VO:   0.010s A:   0.000s Sys:  27.134s =
> > 34.429s
> > BENCHMARK%: VC: 21.1610% VO:  0.0284% A:  0.0000% Sys: 78.8106% =
> > 100.0000%
> > Run2:
> > BENCHMARKs: VC:   7.297s VO:   0.010s A:   0.000s Sys:  23.840s =
> > 31.147s
> > BENCHMARK%: VC: 23.4264% VO:  0.0333% A:  0.0000% Sys: 76.5403% =
> > 100.0000%
> > Run3:
> > BENCHMARKs: VC:   7.225s VO:   0.010s A:   0.000s Sys:  24.222s =
> > 31.457s
> > BENCHMARK%: VC: 22.9691% VO:  0.0322% A:  0.0000% Sys: 76.9987% =
> > 100.0000%
> > (Sys 76% means really 3% sys and the rest is iowait according to vmstat)
> > 
> > With patch:
> > Run1:
> > BENCHMARKs: VC:  10.352s VO:   0.012s A:   0.000s Sys:  85.822s =
> > 96.186s
> > BENCHMARK%: VC: 10.7624% VO:  0.0126% A:  0.0000% Sys: 89.2250% =
> > 100.0000%
> > Run2:
> > BENCHMARKs: VC:  10.093s VO:   0.013s A:   0.000s Sys:  86.267s =
> > 96.374s
> > BENCHMARK%: VC: 10.4729% VO:  0.0140% A:  0.0000% Sys: 89.5132% =
> > 100.0000%
> > Run3:
> > (Sys 89% means really 3% sys and the rest is idle according to vmstat)
> 
> Sys is the time that MPlayer can not account for in any way - most of
> the time that's some blocking syscall, so most likely the patch
> causes MPlayer to hang for for almost 60 additional seconds (out of 100)
> in some syscall.

Well, obviously it takes longer since the internet throughput is
lower as said above, so it has to wait longer for reads in this IO
bound benchmark.

> > I'd assume some bad interaction between asynchroniously asking for
> > those pages and the sshfs implementation...
> 
> I have the impression fadvise is badly tested and suboptimally
> implemented as of today at least.
> Which kernel version did you use for testing?

2.6.32-rc6

-- 
Tobias						PGP: http://8ef7ddba.uguu.de



More information about the MPlayer-dev-eng mailing list