From: Boaz Harrosh <bharrosh@panasas.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux1394-devel@lists.sourceforge.net,
linux-scsi@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [patch resend] firewire: ieee1394: Move away from SG_ALL
Date: Wed, 06 Aug 2008 12:10:21 +0300 [thread overview]
Message-ID: <48996A7D.3080101@panasas.com> (raw)
In-Reply-To: <4898B0AF.6050800@s5r6.in-berlin.de>
Stefan Richter wrote:
> Boaz Harrosh wrote:
>> From my tests, the block layer will, very fast, send you chained commands.
>> if you set it to 255 you'll see two chained fragments. In iscsi we have
>> 4096 and it is very good for performance. However since you are pre-allocating
>> the memory per can_queue commands, this can get big, and the memory overhead
>> can be an impact on performance.
>
> I did repeated read tests with dd now, with a 3.5" 750G SATA/ FireWire
> 800 disk and with a 2.5" 250G IDE/ FireWire 400 disk, each with either
> FireWire stack. I used dd with and without iflag=direct, just because I
> don't have a clue how to capture the influence of .sg_tablesize best.
>
> Tests with .sg_tablesize = 128, 255, and 5000 all yield the same
> transfer rates. So I guess I simply leave it at the current SG_ALL for now.
You will need to enable sg chaining for your device. I'm not sure
where is the latest documentation. (CC: Jens)
Here is the script I used in my tests:
#!/bin/bash
sdx=sdb
# mess with sglist chaining
cd /sys/block/$sdx/queue
echo 4096 > max_segments
cat max_hw_sectors_kb > max_sectors_kb
echo "max_hw_sectors_kb="$(cat max_hw_sectors_kb)
echo "max_sectors_kb="$(cat max_sectors_kb)
echo "max_segments="$(cat max_segments)
Try to view the content of max_segments before and after
see if it changed.
and also with dd you need a large block size here is how
I calculated it. (Other people might have better tests)
I did a write test but a read test should be better:
if=/dev/zero
of=/dev/sdb
outputfile=$1.txt
echo "Testing $1"
# send 32G in $1 sectrors at once
do_dd()
{
# blocks of one sector
bs=512
#memory page in blocks
page=8
#number of scatterlist elements in a transfer
sgs=$1
#calculate the bpt param
bpt=$(($sgs*$page))
#total blocks to transfer 32 Giga bytes
count=64M
echo $3: "bpt=$bpt"
\time bash -c \
"sg_dd blk_sgio=1 dio=1 if=$if of=$of bpt=$bpt bs=$bs count=$count 2>/dev/null" \
2>> $2
}
echo "BEGIN RUN $1" >> $outputfile
echo "run with 128-sgilist"
echo "run with 128-sgilist" >> $outputfile
for i in {1..20}; do
do_dd 128 $outputfile $i;
done
echo "run with 2048-sgilist"
echo "run with 2048-sgilist" >> $outputfile
for i in {1..20}; do
do_dd 2048 $outputfile $i;
done
I think that in the second case with 2048 if your device does
not support it, dd will fail. (if I recall correctly)
Boaz
PS: OK I used sg_dd from sg-utils sg_read might be even better
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
next prev parent reply other threads:[~2008-08-06 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-04 18:08 [patch resend] firewire: ieee1394: Move away from SG_ALL Stefan Richter
2008-08-04 19:21 ` James Bottomley
2008-08-04 19:58 ` Stefan Richter
2008-08-05 12:22 ` Boaz Harrosh
2008-08-05 15:01 ` Stefan Richter
2008-08-05 15:28 ` Boaz Harrosh
2008-08-08 11:59 ` [PATCH] ieee1394: sbp2: stricter dma_sync Stefan Richter
2008-08-08 12:00 ` [PATCH] ieee1394: sbp2: avoid DMA bounce buffers for ORBs Stefan Richter
2008-08-08 17:54 ` Stefan Richter
2008-08-09 18:13 ` [PATCH update] ieee1394: sbp2: stricter dma_sync Stefan Richter
2008-08-09 18:16 ` [PATCH] ieee1394: sbp2: check for DMA mapping failures Stefan Richter
2008-08-05 19:57 ` [patch resend] firewire: ieee1394: Move away from SG_ALL Stefan Richter
2008-08-06 9:10 ` Boaz Harrosh [this message]
2008-08-06 20:49 ` Stefan Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48996A7D.3080101@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox