From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752289Ab2LPVbJ (ORCPT ); Sun, 16 Dec 2012 16:31:09 -0500 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:25074 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750798Ab2LPVbI (ORCPT ); Sun, 16 Dec 2012 16:31:08 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigMAE08zlB5LIoV/2dsb2JhbABFhVKyaIYJF3OCHgEBBAE6HCMQCAMOCi4UJQMhE4gNBbhwFIxJhEMDlgmQSYMH Date: Mon, 17 Dec 2012 08:31:04 +1100 From: Dave Chinner To: Eric Wong Cc: Alan Cox , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue Message-ID: <20121216213104.GO9806@dastard> 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> <20121216052302.GA6680@dcvr.yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121216052302.GA6680@dcvr.yhbt.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 16, 2012 at 05:23:02AM +0000, Eric Wong wrote: > 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. > > From userspace, I don't know when/if I'm caching too much and possibly > getting the userspace cache itself swapped out. Which causes th disk to spin up. Now you start to see the complexity of what you are trying to acheive... > > > 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... > > fadvise() is fairly new, and AFAIK few apps use it. Perhaps if it > were improved, more people would use it and not have to reinvent > the wheel. fadvise() is not "fairly new". It's been around for many, many years - it was there whan the linux kernel moved to git in 2005, and I haven't bothered to look any further back in history... > > 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.... > > I don't want to introduce regressions, either. > > Perhaps if part of the FADV_WILLNEED read-ahead were handled > synchronously (maybe 2M?) and humongous large readaheads (like mine) > went to the background, that would be a good trade off? Which you can already do in userspace yourself without changing the kernel. i.e: main thread background thread: readahead(0, 2MB) spawn background thread read(0, len) readahead(2MB,1GB); Cheers, Dave. -- Dave Chinner david@fromorbit.com