Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755280Ab1CBQOd (ORCPT ); Wed, 2 Mar 2011 11:14:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19113 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753497Ab1CBQOc convert rfc822-to-8bit (ORCPT ); Wed, 2 Mar 2011 11:14:32 -0500 From: Jeff Moyer To: Jan Kara Cc: Corrado Zoccolo , "Alex\,Shi" , "Li\, Shaohua" , Vivek Goyal , "tytso\@mit.edu" , "jaxboe\@fusionio.com" , "linux-kernel\@vger.kernel.org" , "Chen\, Tim C" Subject: Re: [performance bug] kernel building regression on 64 LCPUs machine References: <20110126081529.GA28909@sli10-conroe.sh.intel.com> <1297502512.29573.26.camel@debian> <1297650318.29573.2482.camel@debian> <1297732201.24560.2.camel@sli10-conroe> <20110221164909.GG6584@quack.suse.cz> <1298449487.14712.1064.camel@debian> <20110224121339.GE23042@quack.suse.cz> <20110302094246.GA7496@quack.suse.cz> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Wed, 02 Mar 2011 11:13:53 -0500 In-Reply-To: <20110302094246.GA7496@quack.suse.cz> (Jan Kara's message of "Wed, 2 Mar 2011 10:42:46 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1918 Lines: 42 Jan Kara writes: > On Tue 01-03-11 14:56:43, Jeff Moyer wrote: >> Corrado Zoccolo writes: >> >> > On Thu, Feb 24, 2011 at 1:13 PM, Jan Kara wrote: >> >> On Wed 23-02-11 16:24:47, Alex,Shi wrote: >> >>> Though these patches can not totally recovered the problem, but they are >> >>> quite helpful with ccache enabled situation. It increase 10% performance >> >>> on 38-rc1 kernel. >> >>  OK and what was the original performance drop with WRITE_SYNC change? >> >> >> >>> I have tried to enabled they to latest rc6 kernel but failed. the vmstat output is here: >> >>> with patches: >> >>  I'm attaching patches rebased on top of latest Linus's tree. >> >> Corrado, could you possibly run your fsync-heavy tests so that we see >> >> whether there isn't negative impact of my patches on your fsync-heavy >> >> workload? Thanks. >> > The workload was actually Jeff's, and the stalls that my change tried >> > to mitigate showed up on his enterprise class storage. Adding him so >> > he can test it. >> >> Sorry for the late reply. You can use either fs_mark or iozone to >> generate an fsync-heavy workload. The test I did was to mix this with a >> sequential reader. If you can point me at patches, I should be able to >> test this. > The latest version of patches is attached to: > https://lkml.org/lkml/2011/2/24/125 Perhaps you should fix up the merge conflicts, first? ;-) +<<<<<<< HEAD tid = transaction->t_tid; need_to_start = !tid_geq(journal->j_commit_request, tid); +======= + __jbd2_log_start_commit(journal, transaction->t_tid, false); +>>>>>>> jbd2: Refine commit writeout logic -- 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/