Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932561AbbELLWK (ORCPT ); Tue, 12 May 2015 07:22:10 -0400 Received: from mail.phunq.net ([184.71.0.62]:60658 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932421AbbELLWH (ORCPT ); Tue, 12 May 2015 07:22:07 -0400 Message-ID: <5551E269.3040208@phunq.net> Date: Tue, 12 May 2015 04:22:17 -0700 From: Daniel Phillips User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Pavel Machek CC: "Theodore Ts'o" , Howard Chu , Mike Galbraith , Dave Chinner , 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?) 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> <20150512090300.GA15574@amd> In-Reply-To: <20150512090300.GA15574@amd> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3492 Lines: 72 On 05/12/2015 02:03 AM, Pavel Machek wrote: > On Mon 2015-05-11 19:34:34, Daniel Phillips wrote: >> On 05/11/2015 04:17 PM, Theodore Ts'o wrote: >>> and another way that people >>> doing competitive benchmarking can screw up and produce misleading >>> numbers. >> >> If you think we screwed up or produced misleading numbers, could you >> please be up front about it instead of making insinuations and >> continuing your tirade against benchmarking and those who do it. > > Are not you little harsh with Ted? He was polite. Polite language does not include words like "screw up" and "misleading numbers", those are combative words intended to undermine and disparage. It is not clear how repeating the same words can be construed as less polite than the original utterance. >> The ram disk removes seek overhead and greatly reduces media transfer >> overhead. This does not change things much: it confirms that Tux3 is >> significantly faster than the others at synchronous loads. This is >> apparently true independently of media type, though to be sure SSD >> remains to be tested. >> >> The really interesting result is how much difference there is between >> filesystems, even on a ram disk. Is it just CPU or is it synchronization >> strategy and lock contention? Does our asynchronous front/back design >> actually help a lot, instead of being a disadvantage as you predicted? >> >> It is too bad that fs_mark caps number of tasks at 64, because I am >> sure that some embarrassing behavior would emerge at high task counts, >> as with my tests on spinning disk. > > I'd call system with 65 tasks doing heavy fsync load at the some time > "embarrassingly misconfigured" :-). It is nice if your filesystem can > stay fast in that case, but... Well, Tux3 wins the fsync race now whether it is 1 task, 64 tasks or 10,000 tasks. At the high end, maybe it is just a curiosity, or maybe it tells us something about how Tux3 is will scale on the big machines that XFS currently lays claim to. And Java programmers are busy doing all kinds of wild and crazy things with lots of tasks. Java almost makes them do it. If they need their data durable then they can easily create loads like my test case. Suppose you have a web server meant to serve 10,000 transactions simultaneously and it needs to survive crashes without losing client state. How will you do it? You could install an expensive, finicky database, or you could write some Java code that happens to work well because Linux has a scheduler and a filesystem that can handle it. Oh wait, we don't have the second one yet, but maybe we soon will. I will not claim that stupidly fast and scalable fsync is the main reason that somebody should want Tux3, however, the lack of a high performance fsync was in fact used as a means of spreading FUD about Tux3, so I had some fun going way beyond the call of duty to answer that. By the way, I am still waiting for the original source of the FUD to concede the point politely, but maybe he is waiting for the code to land, which it still has not as of today, so I guess that is fair. Note that it would have landed quite some time ago if Tux3 was already merged. Historical note: didn't Java motivate the O(1) scheduler? Regarda, Daniel -- 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/