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

[Tobias Diedrich]

Tobias Diedrich wrote:
> > > 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

This is what happens (at least on the sshfs side, I did not
crosscheck with the kernel read-ahead code yet):

Without the patch, the normal kernel read-ahead kicks in and
batches it's requests in 64KB blocks.

With the patch, the first prefetch wants the whole 1MB block, so
this gets merged nicely before going to sshfs and cause the
high-speed peak at the beginning.
After that fill_buffer requests additional 2KB at a time which
effectively translates to one Page at a time in the kernel.

Since posix_fadvise has no way to give a deadline, the kernel
assumes 'as soon as possible' and passes the 4KB request down to
sshfs, which has no mechanism for request merging apparently, thus
the slowdown. (I assume you would not see this on a LAN, since you
would not have the big 300ms rtt)

In the 'physical disk' case the elevator merges requests so no
slowdown there.  With the '64KB buffer' patch the slowdown is gone
and sshfs sees 64KB requests again, confirming this so far.

The fix is to batch the fadvise calls instead of calling it for
every 2KB block....

AFAICS the kernel implementation is reasonable, the problem is there
is no 'practical implementation tips' in the manpage and on the
other hand sshfs relies to much on the kernel doing request merging
and probably should implement some request merging mechanism itself.

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