From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754772AbZCOEJT (ORCPT ); Sun, 15 Mar 2009 00:09:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751751AbZCOEJH (ORCPT ); Sun, 15 Mar 2009 00:09:07 -0400 Received: from phunq.net ([64.81.85.152]:58420 "EHLO moonbase.phunq.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751384AbZCOEJG (ORCPT ); Sun, 15 Mar 2009 00:09:06 -0400 From: Daniel Phillips To: Nick Piggin Subject: Re: [Tux3] Tux3 report: Tux3 Git tree available Date: Sat, 14 Mar 2009 21:08:52 -0700 User-Agent: KMail/1.9.9 Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, tux3@tux3.org, Andrew Morton , linux-kernel@vger.kernel.org References: <200903110925.37614.phillips@phunq.net> <200903142024.30142.phillips@phunq.net> <200903151450.51726.nickpiggin@yahoo.com.au> In-Reply-To: <200903151450.51726.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903142108.53155.phillips@phunq.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 14 March 2009, Nick Piggin wrote: > On Sunday 15 March 2009 14:24:29 Daniel Phillips wrote: > > I expect implementing VM extents to be a brutally complex project, as > > filesystem extents always turn out to be, even though one tends to > > enter such projects thinking, how hard could this be? Answer: harder > > than you think. But VM extents would be good for a modest speedup, so > > somebody is sure to get brave enough to try it sometime. > > I don't think there is enough evidence to be able to make such an > assertion. > > When you actually implement extent splitting and merging in a deadlock > free manner and synchronize everything properly I wouldn't be surprised > if it is slower most of the time. If it was significantly faster, then > memory fragmentation means that it is going to get significantly slower > over the uptime of the kernel, so you would have to virtually map the > kernel and implement memory defragmentation, at which point you get even > slower and more complex. You can make exactly the same argument about filesystem extents, and we know that extents are faster there. So what is the fundamental difference? Regards, Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: Tux3 report: Tux3 Git tree available Date: Sat, 14 Mar 2009 21:08:52 -0700 Message-ID: <200903142108.53155.phillips@phunq.net> References: <200903110925.37614.phillips@phunq.net> <200903142024.30142.phillips@phunq.net> <200903151450.51726.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, tux3@tux3.org, Andrew Morton , linux-kernel@vger.kernel.org, Matthew Wilcox To: Nick Piggin Return-path: In-Reply-To: <200903151450.51726.nickpiggin@yahoo.com.au> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tux3-bounces@tux3.org Errors-To: tux3-bounces@tux3.org List-Id: linux-fsdevel.vger.kernel.org On Saturday 14 March 2009, Nick Piggin wrote: > On Sunday 15 March 2009 14:24:29 Daniel Phillips wrote: > > I expect implementing VM extents to be a brutally complex project, as > > filesystem extents always turn out to be, even though one tends to > > enter such projects thinking, how hard could this be? Answer: harder > > than you think. But VM extents would be good for a modest speedup, so > > somebody is sure to get brave enough to try it sometime. > > I don't think there is enough evidence to be able to make such an > assertion. > > When you actually implement extent splitting and merging in a deadlock > free manner and synchronize everything properly I wouldn't be surprised > if it is slower most of the time. If it was significantly faster, then > memory fragmentation means that it is going to get significantly slower > over the uptime of the kernel, so you would have to virtually map the > kernel and implement memory defragmentation, at which point you get even > slower and more complex. You can make exactly the same argument about filesystem extents, and we know that extents are faster there. So what is the fundamental difference? Regards, Daniel