public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: FUJITA Tomonori <tomof@acm.org>
To: linux-scsi@vger.kernel.org
Cc: jens.axboe@oracle.com, James.Bottomley@SteelEye.com,
	fujita.tomonori@lab.ntt.co.jp
Subject: [PATCH 1/2] revert sg segment size ifdefs
Date: Mon, 3 Sep 2007 18:40:20 +0900	[thread overview]
Message-ID: <20070903103501F.tomof@acm.org> (raw)

The patchset is against Jens' sg chaining branch.

Jens removed old SCSI_MAX_PHYS_SEGMENTS hack and the maximum is always
128:

http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=d6beb57f48231f5c012fb7d55b369bc0af6b0c41

I talked to James at linuxconf.eu and he likes to provide a way to
reduce sgpool memory consumption because with libata everyone
(including small machines) uses the mid layer.

This patch reverts sg segment size ifdefs that the current mid layer
has. Later we might do something better like relating
SCSI_MAX_SG_SEGMENTS with other config options like CONFIG_EMBEDDED or
just having SCSI_MAX_SG_SEGMENTS in menuconfig.

Now we have sg chaining code in -mm. As discussed before, it would be
nice to test sg chaining code in -mm with a small SCSI_MAX_SG_SEGMENTS
value like 32.

---
>From 4692956cdc3db1d0cfb3f26dc7aa3925f591d392 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Sat, 18 Aug 2007 19:00:47 +0900
Subject: [PATCH 1/2] revert sg segment size ifdefs

This reverts sg segment size ifdefs that the current code has in order
to provide a way to reduce sgpool memory consumption.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 drivers/scsi/scsi_lib.c |   28 ++++++++++++++++++++--------
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f05f006..2fc2380 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -34,6 +34,13 @@
 #define SG_MEMPOOL_NR		ARRAY_SIZE(scsi_sg_pools)
 #define SG_MEMPOOL_SIZE		2
 
+/*
+ * The maximum number of SG segments that we will put inside a scatterlist
+ * (unless chaining is used). Should ideally fit inside a single page, to
+ * avoid a higher order allocation.
+ */
+#define SCSI_MAX_SG_SEGMENTS	128
+
 struct scsi_host_sg_pool {
 	size_t		size;
 	char		*name;
@@ -45,9 +52,15 @@ struct scsi_host_sg_pool {
 static struct scsi_host_sg_pool scsi_sg_pools[] = {
 	SP(8),
 	SP(16),
+#if (SCSI_MAX_SG_SEGMENTS > 16)
 	SP(32),
+#if (SCSI_MAX_SG_SEGMENTS > 32)
 	SP(64),
+#if (SCSI_MAX_SG_SEGMENTS > 64)
 	SP(128),
+#endif
+#endif
+#endif
 };
 #undef SP
 
@@ -690,13 +703,6 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd *cmd, int uptodate,
 }
 
 /*
- * The maximum number of SG segments that we will put inside a scatterlist
- * (unless chaining is used). Should ideally fit inside a single page, to
- * avoid a higher order allocation.
- */
-#define SCSI_MAX_SG_SEGMENTS	128
-
-/*
  * Like SCSI_MAX_SG_SEGMENTS, but for archs that have sg chaining. This limit
  * is totally arbitrary, a setting of 2048 will get you at least 8mb ios.
  */
@@ -713,15 +719,21 @@ static inline unsigned int scsi_sgtable_index(unsigned short nents)
 	case 9 ... 16:
 		index = 1;
 		break;
+#if (SCSI_MAX_SG_SEGMENTS > 16)
 	case 17 ... 32:
 		index = 2;
 		break;
+#if (SCSI_MAX_SG_SEGMENTS > 32)
 	case 33 ... 64:
 		index = 3;
 		break;
-	case 65 ... SCSI_MAX_SG_SEGMENTS:
+#if (SCSI_MAX_SG_SEGMENTS > 64)
+	case 65 ... 128:
 		index = 4;
 		break;
+#endif
+#endif
+#endif
 	default:
 		printk(KERN_ERR "scsi: bad segment count=%d\n", nents);
 		BUG();
-- 
1.5.2.4


             reply	other threads:[~2007-09-03  9:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-03  9:40 FUJITA Tomonori [this message]
2007-09-03 10:30 ` [PATCH 1/2] revert sg segment size ifdefs Jens Axboe

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=20070903103501F.tomof@acm.org \
    --to=tomof@acm.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    /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