Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933460AbYAaQ5V (ORCPT ); Thu, 31 Jan 2008 11:57:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758387AbYAaQ5M (ORCPT ); Thu, 31 Jan 2008 11:57:12 -0500 Received: from scalableinformatics.com ([66.93.0.201]:39425 "EHLO mail.scalableinformatics.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757041AbYAaQ5K (ORCPT ); Thu, 31 Jan 2008 11:57:10 -0500 X-Greylist: delayed 1898 seconds by postgrey-1.27 at vger.kernel.org; Thu, 31 Jan 2008 11:57:10 EST Message-ID: <47A1F67C.4020300@scalableinformatics.com> Date: Thu, 31 Jan 2008 11:25:32 -0500 From: Joe Landman Reply-To: landman@scalableinformatics.com Organization: Scalable Informatics User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Vladislav Bolkhovitin CC: Bart Van Assche , James.Bottomley@hansenpartnership.com, linux-scsi@vger.kernel.org, rdreier@cisco.com, linux-kernel@vger.kernel.org, "Nicholas A. Bellinger" , fujita.tomonori@lab.ntt.co.jp, scst-devel@lists.sourceforge.net, akpm@linux-foundation.org, FUJITA Tomonori , torvalds@linux-foundation.org Subject: Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel References: <20080130083239E.fujita.tomonori@lab.ntt.co.jp> <20080130195635T.tomof@acm.org> <1201785938.7280.105.camel@haakon2.linux-iscsi.org> <47A1EE54.6000005@vlnb.net> In-Reply-To: <47A1EE54.6000005@vlnb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2781 Lines: 77 Vladislav Bolkhovitin wrote: > Bart Van Assche wrote: [...] >> I can run disktest on the same setups I ran dd on. This will take some >> time however. > > Disktest was already referenced in the beginning of the performance > comparison thread, but its results are not very interesting if we are > going to find out, which implementation is more effective, because in > the modes, in which usually people run this utility, it produces latency > insensitive workload (multiple threads working in parallel). So, such There are other issues with disktest, in that you can easily specify option combinations that generate apparently 5+ GB/s of IO, though actual traffic over the link to storage is very low. Caveat disktest emptor. > multithreaded disktests results will be different between STGT and SCST > only if STGT's implementation will get target CPU bound. If CPU on the > target is powerful enough, even extra busy loops in the STGT or SCST hot > path code will change nothing. > > Additionally, multithreaded disktest over RAM disk is a good example of > a synthetic benchmark, which has almost no relation with real life > workloads. But people like it, because it produces nice looking results. I agree. The backing store should be a disk for it to have meaning, though please note my caveat above. > > Actually, I don't know what kind of conclusions it is possible to make > from disktest's results (maybe only how throughput gets bigger or slower > with increasing number of threads?), it's a good stress test tool, but > not more. Unfortunately, I agree. Bonnie++, dd tests, and a few others seem to bear far closer to "real world" tests than disktest and iozone, the latter of which does more to test the speed of RAM cache and system call performance than actual IO. >> Disktest is new to me -- any hints with regard to suitable >> combinations of command line parameters are welcome. The most recent >> version I could find on http://ltp.sourceforge.net/ is ltp-20071231. >> >> Bart Van Assche. Here is what I have run: disktest -K 8 -B 256k -I F -N 20000000 -P A -w /big/file disktest -K 8 -B 64k -I F -N 20000000 -P A -w /big/file disktest -K 8 -B 1k -I B -N 2000000 -P A /dev/sdb2 and many others. Joe -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics LLC, email: landman@scalableinformatics.com web : http://www.scalableinformatics.com http://jackrabbit.scalableinformatics.com phone: +1 734 786 8423 fax : +1 866 888 3112 cell : +1 734 612 4615 -- 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/