From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id 6437A6B002B for ; Sun, 16 Dec 2012 03:35:41 -0500 (EST) Received: by mail-pb0-f41.google.com with SMTP id xa7so3177972pbc.14 for ; Sun, 16 Dec 2012 00:35:40 -0800 (PST) Date: Sun, 16 Dec 2012 16:48:59 +0800 From: Zheng Liu Subject: Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue Message-ID: <20121216084859.GA5600@gmail.com> References: <20121215005448.GA7698@dcvr.yhbt.net> <20121215223448.08272fd5@pyramind.ukuu.org.uk> <20121216002549.GA19402@dcvr.yhbt.net> <20121216030302.GI9806@dastard> <20121216033549.GA30446@dcvr.yhbt.net> <20121216041549.GK9806@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121216041549.GK9806@dastard> Sender: owner-linux-mm@kvack.org List-ID: To: Dave Chinner Cc: Eric Wong , Alan Cox , linux-mm@kvack.org, linux-kernel@vger.kernel.org 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 wrote: > > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote: > > > > Alan Cox wrote: > > > > > On Sat, 15 Dec 2012 00:54:48 +0000 > > > > > Eric Wong 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org