lkml.org 
[lkml]   [2012]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote:
> Dave Chinner <david@fromorbit.com> wrote:
> > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote:
> > > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > > On Sat, 15 Dec 2012 00:54:48 +0000
> > > > Eric Wong <normalperson@yhbt.net> wrote:
> > > >
> > > > > Applications streaming large files may want to reduce disk spinups and
> > > > > I/O latency by performing large amounts of readahead up front

> This could also be a use case for an audio/video player.

Sure, but this can all be handled by a userspace application. If you
want to avoid/batch IO to enable longer spindown times, then you
have to load the file into RAM somewhere, and you don't need special
kernel support for that.

> So no, there's no difference that matters between the approaches.
> But I think doing this in the kernel is easier for userspace users.

The kernel provides mechanisms for applications to use. You have not
mentioned anything new that requires a new kernel mechanism to
acheive - you just need to have the knowledge to put the pieces
together properly. People have been solving this same problem for
the last 20 years without needing to tweak fadvise(). Or even having
an fadvise() syscall...

Nothing about low latency IO or streaming IO is simple or easy, and
changing how readahead works doesn't change that fact. All it does
is change the behaviour of every other application that uses
fadvise() to minimise IO latency....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com


\
 
 \ /
  Last update: 2012-12-16 05:21    [W:0.091 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site