Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbbELFjB (ORCPT ); Tue, 12 May 2015 01:39:01 -0400 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:26874 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752211AbbELFi6 (ORCPT ); Tue, 12 May 2015 01:38:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BiBwDikFFV//DOLHlcgw+BMrMaAQEBAQEBBplVBAICgTxNAQEBAQEBgQuEIAEBAQMBOhwjBQsIAxgJGgsPBSUDIROIJAfIcwELIBiFfoUjgSODYgeELQWdI4ElkWGDVSOCOoFPLDGCRgEBAQ Date: Tue, 12 May 2015 15:38:42 +1000 From: Dave Chinner To: Daniel Phillips Cc: "Theodore Ts'o" , Pavel Machek , Howard Chu , Mike Galbraith , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, tux3@tux3.org, OGAWA Hirofumi Subject: Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?) Message-ID: <20150512053842.GH15721@dastard> References: <1430395641.3180.94.camel@gmail.com> <1430401693.3180.131.camel@gmail.com> <55423732.2070509@phunq.net> <55423C05.1000506@symas.com> <554246D7.40105@phunq.net> <20150511221223.GD4434@amd> <20150511231714.GD14088@thunk.org> <555166BA.1050606@phunq.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555166BA.1050606@phunq.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 Content-Length: 1772 Lines: 42 On Mon, May 11, 2015 at 07:34:34PM -0700, Daniel Phillips wrote: > Anyway, everybody but you loves competitive benchmarks, that is why I I think Ted and I are on the same page here. "Competitive benchmarks" only matter to the people who are trying to sell something. You're trying to sell Tux3, but.... > post them. They are not only useful for tracking down performance bugs, > but as you point out, they help us advertise the reasons why Tux3 is > interesting and ought to be merged. .... benchmarks won't get tux3 merged. Addressing the significant issues that have been raised during previous code reviews is what will get it merged. I posted that list elsewhere in this thread which you replied that they were all "on the list of things to do except for the page forking design". The "except page forking design" statement is your biggest hurdle for getting tux3 merged, not performance. Without page forking, tux3 cannot be merged at all. But it's not filesystem developers you need to convince about the merits of the page forking design and implementation - it's the mm and core kernel developers that need to review and accept that code *before* we can consider merging tux3. IOWs, you need to focus on the important things needed to acheive your stated goal of getting tux3 merged. New filesystems should be faster than those based on 20-25 year old designs, so you don't need to waste time trying to convince people that tux3, when complete, will be fast. Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/