Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764735AbZDBJCt (ORCPT ); Thu, 2 Apr 2009 05:02:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753761AbZDBJCi (ORCPT ); Thu, 2 Apr 2009 05:02:38 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:63214 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752858AbZDBJCg (ORCPT ); Thu, 2 Apr 2009 05:02:36 -0400 Message-ID: <49D47F28.3060409@vlnb.net> Date: Thu, 02 Apr 2009 13:02:32 +0400 From: Vladislav Bolkhovitin User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: James Bottomley CC: "linux-scsi@vger.kernel.org" , iSCSI Enterprise Target Developer List , "linux-kernel@vger.kernel.org" , Ross Walker , "Ross S. W. Walker" , scst-devel , "stgt@vger.kernel.org" Subject: Re: [Scst-devel] [Iscsitarget-devel] ISCSI-SCST performance (with also IET and STGT data) References: <49D10256.8030307@vlnb.net> <49D11096.3070804@vlnb.net> <49D254E4.8050806@vlnb.net> <1238617423.3318.82.camel@mulgrave.int.hansenpartnership.com> <49D46B8B.5000708@vlnb.net> In-Reply-To: <49D46B8B.5000708@vlnb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19VCQ0HP3twyHEtOTIV4faFQXyQHx3LT9ADwfQ 5OQQP9puFbkNixz9Bm1ba7e1k9gPBdk7ycKHlfYcpXkCTaykTS 7vc3KbMcLTNVbGXCC1b6A== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2807 Lines: 57 Vladislav Bolkhovitin, on 04/02/2009 11:38 AM wrote: > James Bottomley, on 04/02/2009 12:23 AM wrote: >> On Wed, 2009-04-01 at 08:20 -0400, Ross Walker wrote: >>> On Apr 1, 2009, at 2:29 AM, Bart Van Assche >>> wrote: >>> >>>> On Tue, Mar 31, 2009 at 8:43 PM, Ross S. W. Walker >>>> wrote: >>>>> IET just needs to fix how it does it workload with CFQ which >>>>> somehow SCST has overcome. Of course SCST tweaks the Linux kernel to >>>>> gain some extra speed. >>>> I'm not familiar with the implementation details of CFQ, but I know >>>> that one of the changes between SCST 1.0.0 and SCST 1.0.1 is that the >>>> default number of kernel threads of the scst_vdisk kernel module has >>>> been increased to 5. Could this explain the performance difference >>>> between SCST and IET for FILEIO and BLOCKIO ? >>> Thank for the update. IET has used 8 threads per target for ages now, >>> I don't think it is that. >>> >>> It may be how the I/O threads are forked in SCST that causes them to >>> be in the same I/O context with each other. >>> >>> I'm pretty sure implementing a version of the patch that was used for >>> the dump command (found on the LKML) will fix this. >>> >>> But thanks goes to Vlad for pointing this dificiency out so we can fix >>> it to help make IET even better. >> SCST explicitly fiddles with the io context to get this to happen. It >> has a hack to block to export alloc_io_context: >> >> http://marc.info/?t=122893564800003 > > Correct, although I wouldn't call it "fiddle", rather "grouping" ;) > > But that's not the only reason for good performance. Particularly, it > can't explain Bart's tmpfs results from the previous message, where the > majority of I/O done to/from RAM without any I/O scheduler involved. (Or > does I/O scheduler also involved with tmpfs?) Bart has 4GB RAM, if I > remember correctly, i.e. the test data set was 25% of RAM. To remove any suspicions that I'm playing dirty games here I should note that in many cases I can't say what exactly is responsible for good SCST performance. I can say only something like "good design and implementation", but, I guess, it wouldn't be counted too much. SCST/iSCSI-SCST from the very beginning were designed and made with the best performance in mind and that has brought the result. Sorry, but at the moment I can't afford doing any "why it's so good?" kinds of investigations, because I have a lot more important things to do, like SCST procfs -> sysfs interface conversion. Thanks, Vlad -- 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/