From: Dan Williams Subject: Re: ext4 write performance regression in 3.6-rc1 on RAID0/5 Date: Wed, 22 Aug 2012 13:47:07 -0700 Message-ID: References: <20120816024654.GB3781@thunk.org> <20120816111051.GA16036@localhost> <20120816152513.GA31346@thunk.org> <20120817060915.GB28786@localhost> <20120817134039.GB11439@thunk.org> <20120817142526.GA1059@localhost> <20120822035702.GF2570@yliu-dev.sh.intel.com> <20120822160025.272188d1@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Yuanhan Liu , Fengguang Wu , Li Shaohua , "Theodore Ts'o" , Marti Raudsepp , Kernel hackers , ext4 hackers , maze@google.com, "Shi, Alex" , linux-fsdevel@vger.kernel.org, linux RAID To: NeilBrown Return-path: Received: from mail-qc0-f180.google.com ([209.85.216.180]:63615 "EHLO mail-qc0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508Ab2HVUrJ (ORCPT ); Wed, 22 Aug 2012 16:47:09 -0400 In-Reply-To: <20120822160025.272188d1@notabene.brown> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Tue, Aug 21, 2012 at 11:00 PM, NeilBrown wrote: > On Wed, 22 Aug 2012 11:57:02 +0800 Yuanhan Liu > wrote: > >> >> -#define NR_STRIPES 256 >> +#define NR_STRIPES 1024 > > Changing one magic number into another magic number might help your case, but > it not really a general solution. > > Possibly making sure that max_nr_stripes is at least some multiple of the > chunk size might make sense, but I wouldn't want to see a very large multiple. > > I thing the problems with RAID5 are deeper than that. Hopefully I'll figure > out exactly what the best fix is soon - I'm trying to look into it. > > I don't think the size of the cache is a big part of the solution. I think > correct scheduling of IO is the real answer. Not sure if this is what we are seeing here, but we still have the unresolved fast parity effect whereby slower parity calculation gives a larger time to coalesce writes. I saw this effect when playing with xor offload. -- Dan