Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Jens Axboe
On Mon, Jul 16 2007, Kai Makisara wrote:
> On Mon, 16 Jul 2007, Martin K. Petersen wrote:
> 
> > > "John" == John Stoffel <[EMAIL PROTECTED]> writes:
> > 
> > John> Will this help out tape drive performance at all?  I looked
> > John> through the patches quickly, esp the AIC7xxx stuff since that's
> > John> what I use, but nothing jumped out at me...
> > 
> > Yes.  Most modern tape drives want a block size of 1MB or higher.
> > With the old stack we'd be stuck at 512KB because the sg limitations
> > caused us to come just short of 1MB...
> > 
> Tape block sizes up to 16 MB have been possible for a very long time but 
> this has required tuning of the block/scsi parameters. Very few people 
> seem to have done this and the common (mis)belief seems to be that the 
> tape block size limit has been 512 kB. It is good if this tuning is not
> needed in future.

The main difference is now you get to do it without hacks and in a clean
way, so it works through the normal IO path and not some on-the-side
thing (or st only).

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Kai Makisara
On Mon, 16 Jul 2007, Martin K. Petersen wrote:

> > "John" == John Stoffel <[EMAIL PROTECTED]> writes:
> 
> John> Will this help out tape drive performance at all?  I looked
> John> through the patches quickly, esp the AIC7xxx stuff since that's
> John> what I use, but nothing jumped out at me...
> 
> Yes.  Most modern tape drives want a block size of 1MB or higher.
> With the old stack we'd be stuck at 512KB because the sg limitations
> caused us to come just short of 1MB...
> 
Tape block sizes up to 16 MB have been possible for a very long time but 
this has required tuning of the block/scsi parameters. Very few people 
seem to have done this and the common (mis)belief seems to be that the 
tape block size limit has been 512 kB. It is good if this tuning is not
needed in future.

-- 
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Jens Axboe
On Mon, Jul 16 2007, Martin K. Petersen wrote:
> > "John" == John Stoffel <[EMAIL PROTECTED]> writes:
> 
> John> Will this help out tape drive performance at all?  I looked
> John> through the patches quickly, esp the AIC7xxx stuff since that's
> John> what I use, but nothing jumped out at me...
> 
> Yes.  Most modern tape drives want a block size of 1MB or higher.
> With the old stack we'd be stuck at 512KB because the sg limitations
> caused us to come just short of 1MB...

Indeed. John, note that the driver changes aren't related to enabling
some hardware feature. Drivers just need to be converted to use the sg
walker helpers instead of doing it manually, then they'll also gain
larger IO support. The SCSI drivers are currently being transitioned to
that seperately, my patchset just contains patches for remaining drivers
(which include non-SCSI ones as well).

The hardware has to support a big number of segments of course, looking
at aic7xxx it seems to be limited at 128. From the comment that looks
like it can be increased though, see AHD_NSEG in
drivers/scsi/aic7xxx/aic79xx_osm.h:

/*
 * Number of SG segments we require.  So long as the S/G segments for
 * a particular transaction are allocated in a physically contiguous
 * manner and are allocated below 4GB, the number of S/G segments is
 * unrestricted.
 */
#define AHD_NSEG 128

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread John Stoffel

Jens> A repost of this patchset, which adds support forchaining of sg
Jens> tables.  This enables much larger IO commands, since we don't
Jens> have to allocate large consecutive pieces of memory to represent
Jens> the sgtable of a huge command. Right now Linux is limited to
Jens> somewhere between 128 and 256 segments, depending on the
Jens> architecture. This translates into at most 512k-1mb request
Jens> sizes. With this patchset, I've successfully pushed 10MiB
Jens> commands through the IO stack.

Will this help out tape drive performance at all?  I looked through
the patches quickly, esp the AIC7xxx stuff since that's what I use,
but nothing jumped out at me...

John
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Martin K. Petersen
> "John" == John Stoffel <[EMAIL PROTECTED]> writes:

John> Will this help out tape drive performance at all?  I looked
John> through the patches quickly, esp the AIC7xxx stuff since that's
John> what I use, but nothing jumped out at me...

Yes.  Most modern tape drives want a block size of 1MB or higher.
With the old stack we'd be stuck at 512KB because the sg limitations
caused us to come just short of 1MB...

-- 
Martin K. Petersen  Oracle Linux Engineering

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Jens Axboe
On Mon, Jul 16 2007, FUJITA Tomonori wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Subject: [PATCH 00/33] SG table chaining support
> Date: Mon, 16 Jul 2007 11:47:14 +0200
> 
> > Changes since last post:
> > 
> > - Rebase to current -git. Lots of SCSI drivers have been converted
> >   to use the sg accessor helpers, which nicely shrinks this patchset
> >   from 70 to 33 patches. Great!
> 
> It's against Jens' sglist branch though there are lots of changes to
> the data path in Mike's iscsi tree.
> 
> ---
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [PATCH] iscsi_tcp: sg chaining support

Thanks, applied!

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread Jens Axboe
On Mon, Jul 16 2007, FUJITA Tomonori wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Subject: [PATCH 00/33] SG table chaining support
> Date: Mon, 16 Jul 2007 11:47:14 +0200
> 
> > Changes since last post:
> > 
> > - Rebase to current -git. Lots of SCSI drivers have been converted
> >   to use the sg accessor helpers, which nicely shrinks this patchset
> >   from 70 to 33 patches. Great!
> 
> ---
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [PATCH] ips: sg chaining support
> 
> ips properly uses scsi_for_each_sg for the normal I/O path, however,
> the breakup path doesn't.
> 
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>

Thanks, applied!

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread FUJITA Tomonori
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: [PATCH 00/33] SG table chaining support
Date: Mon, 16 Jul 2007 11:47:14 +0200

> Changes since last post:
> 
> - Rebase to current -git. Lots of SCSI drivers have been converted
>   to use the sg accessor helpers, which nicely shrinks this patchset
>   from 70 to 33 patches. Great!

It's against Jens' sglist branch though there are lots of changes to
the data path in Mike's iscsi tree.

---
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] iscsi_tcp: sg chaining support

Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
 drivers/scsi/iscsi_tcp.c |   41 ++---
 1 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index aebcd5f..4598231 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -316,7 +316,7 @@ iscsi_solicit_data_init(struct iscsi_con
 
sg = scsi_sglist(sc);
r2t->sg = NULL;
-   for (i = 0; i < scsi_sg_count(sc); i++, sg += 1) {
+   for (i = 0; i < scsi_sg_count(sc); i++, sg = sg_next(sg)) {
/* FIXME: prefetch ? */
if (sg_count + sg->length > r2t->data_offset) {
int page_offset;
@@ -332,7 +332,7 @@ iscsi_solicit_data_init(struct iscsi_con
r2t->sendbuf.sg.length -= page_offset;
 
/* xmit logic will continue with next one */
-   r2t->sg = sg + 1;
+   r2t->sg = sg_next(sg);;
break;
}
sg_count += sg->length;
@@ -707,18 +707,21 @@ static int iscsi_scsi_data_in(struct isc
sg = scsi_sglist(sc);
 
if (tcp_ctask->data_offset)
-   for (i = 0; i < tcp_ctask->sg_count; i++)
-   offset -= sg[i].length;
+   for (i = 0; i < tcp_ctask->sg_count; i++, sg = sg_next(sg))
+   offset -= sg->length;
/* we've passed through partial sg*/
if (offset < 0)
offset = 0;
 
-   for (i = tcp_ctask->sg_count; i < scsi_sg_count(sc); i++) {
+   for (i = 0, sg = scsi_sglist(sc); i < tcp_ctask->sg_count; i++)
+   sg = sg_next(sg);
+
+   for (i = tcp_ctask->sg_count; i < scsi_sg_count(sc); i++, sg = 
sg_next(sg)) {
char *dest;
 
-   dest = kmap_atomic(sg[i].page, KM_SOFTIRQ0);
-   rc = iscsi_ctask_copy(tcp_conn, ctask, dest + sg[i].offset,
- sg[i].length, offset);
+   dest = kmap_atomic(sg->page, KM_SOFTIRQ0);
+   rc = iscsi_ctask_copy(tcp_conn, ctask, dest + sg->offset,
+ sg->length, offset);
kunmap_atomic(dest, KM_SOFTIRQ0);
if (rc == -EAGAIN)
/* continue with the next SKB/PDU */
@@ -728,13 +731,13 @@ static int iscsi_scsi_data_in(struct isc
if (!offset)
crypto_hash_update(
&tcp_conn->rx_hash,
-   &sg[i], sg[i].length);
+   sg, sg->length);
else
partial_sg_digest_update(
&tcp_conn->rx_hash,
-   &sg[i],
-   sg[i].offset + offset,
-   sg[i].length - offset);
+   sg,
+   sg->offset + offset,
+   sg->length - offset);
}
offset = 0;
tcp_ctask->sg_count++;
@@ -746,9 +749,9 @@ static int iscsi_scsi_data_in(struct isc
 * data-in is complete, but buffer not...
 */
partial_sg_digest_update(&tcp_conn->rx_hash,
-&sg[i],
-sg[i].offset,
-sg[i].length-rc);
+sg,
+sg->offset,
+sg->length - rc);
rc = 0;
break;
}
@@ -1246,7 +1249,7 @@ iscsi_

Re: [PATCH 00/33] SG table chaining support

2007-07-16 Thread FUJITA Tomonori
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: [PATCH 00/33] SG table chaining support
Date: Mon, 16 Jul 2007 11:47:14 +0200

> Changes since last post:
> 
> - Rebase to current -git. Lots of SCSI drivers have been converted
>   to use the sg accessor helpers, which nicely shrinks this patchset
>   from 70 to 33 patches. Great!

---
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] ips: sg chaining support

ips properly uses scsi_for_each_sg for the normal I/O path, however,
the breakup path doesn't.

Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
 drivers/scsi/ips.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 9f8ed6b..cc5ac4f 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -3251,7 +3251,7 @@ ips_done(ips_ha_t * ha, ips_scb_t * scb)
 */
if ((scb->breakup) || (scb->sg_break)) {
 struct scatterlist *sg;
-int sg_dma_index, ips_sg_index = 0;
+int i, sg_dma_index, ips_sg_index = 0;
 
/* we had a data breakup */
scb->data_len = 0;
@@ -3260,20 +3260,22 @@ ips_done(ips_ha_t * ha, ips_scb_t * scb)
 
 /* Spin forward to last dma chunk */
 sg_dma_index = scb->breakup;
+for (i = 0; i < scb->breakup; i++)
+sg = sg_next(sg);
 
/* Take care of possible partial on last chunk */
 ips_fill_scb_sg_single(ha,
-   
sg_dma_address(&sg[sg_dma_index]),
+   sg_dma_address(sg),
scb, ips_sg_index++,
-   sg_dma_len(&sg[sg_dma_index]));
+   sg_dma_len(sg));
 
 for (; sg_dma_index < scsi_sg_count(scb->scsi_cmd);
- sg_dma_index++) {
+ sg_dma_index++, sg = sg_next(sg)) {
 if (ips_fill_scb_sg_single
 (ha,
- sg_dma_address(&sg[sg_dma_index]),
+ sg_dma_address(sg),
  scb, ips_sg_index++,
- sg_dma_len(&sg[sg_dma_index])) < 0)
+ sg_dma_len(sg)) < 0)
 break;
 }
 
-- 
1.4.3.2

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/33] SG table chaining support

2007-07-16 Thread Jens Axboe
Hi,

A repost of this patchset, which adds support forchaining of sg tables.
This enables much larger IO commands, since we don't have to allocate
large consecutive pieces of memory to represent the sgtable of a
huge command. Right now Linux is limited to somewhere between 128 and 256
segments, depending on the architecture. This translates into at most
512k-1mb request sizes. With this patchset, I've successfully pushed
10MiB commands through the IO stack.

This will potentially increase performance a lot on hardware that
requires larger IO commands to perform at their maximum.

Also see http://marc.info/?l=linux-kernel&m=117869783524152

To enable large IO commands for device sda, you would do:

# cd /sys/block/sda/queue
# echo 4096 > max_segments
# cat max_hw_sectors_kb  > max_sectors_kb

cat max_hw_sectors_kb to see what your largest IO size would now be.

Changes since last post:

- Rebase to current -git. Lots of SCSI drivers have been converted
  to use the sg accessor helpers, which nicely shrinks this patchset
  from 70 to 33 patches. Great!

-- 
Jens Axboe



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html