Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Dec 16, 2012 at 03:15:49PM +1100, Dave Chinner wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote:
> > Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote:
> > > > Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +0000
> > > > > Eric Wong <normalperson@xxxxxxxx> 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....

Hi Dave,

I am wondering this patch might be a good idea to reduce the latency of
fadvise() syscall itself.  I do a really simple test in my desktop to
measure the latency of fadvise syscall.  Before applying this patch,
fadvise syscall takes 32 microseconds.  After applying the patch, it
only takes 4 microseconds. (I was surprised that it takes a very long
time!)

Actually we observe a latency after using fadvise.  But I don't find a
proper time to look at this problem.  So I guess this patch might be
useful to reduce latency.

Regards,
                                                - Zheng

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]