All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Chris Mason <mason@suse.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] 2.4.x write barriers (updated for ext3)
Date: Thu, 28 Feb 2002 20:08:26 -0600	[thread overview]
Message-ID: <200203010208.g2128Qq01694@localhost.localdomain> (raw)
In-Reply-To: Message from Chris Mason <mason@suse.com>  of "Thu, 28 Feb 2002 13:12:40 EST." <3903140000.1014919960@tiny>

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

mason@suse.com said:
> So, a little testing with scsi_info shows my scsi drives do have
> writeback cache on.  great.  What's interesting is they must be doing
> additional work for ordered tags.  If they were treating the block as
> written once in cache, using the tags should not change  performance
> at all.  But, I can clearly show the tags changing performance, and
> hear the drive write pattern change when tags are on. 

I checked all mine and they're write through.  However, I inherited all my 
drives from an enterprise vendor so this might not be that surprising.

I can surmise why ordered tags kill performance on your drive, since an 
ordered tag is required to affect the ordering of the write to the medium, not 
the cache, it is probably implemented with an implicit cache flush.

Anyway, the attached patch against 2.4.18 (and I know it's rather gross code) 
will probe the cache type and try to set it to write through on boot.  See 
what this does to your performance ordinarily, and also to your tagged write 
barrier performance.

James



[-- Attachment #2: sd-cache.diff --]
[-- Type: text/plain , Size: 3973 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.166   -> 1.167  
#	   drivers/scsi/sd.c	1.18    -> 1.19   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/02/28	jejb@malley.il.steeleye.com	1.167
# changes in sd driver
# 
# Drive cache set to write back if possible.
# --------------------------------------------
#
diff -Nru a/drivers/scsi/sd.c b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c	Thu Feb 28 20:04:49 2002
+++ b/drivers/scsi/sd.c	Thu Feb 28 20:04:49 2002
@@ -741,7 +741,7 @@
 	char nbuff[6];
 	unsigned char *buffer;
 	unsigned long spintime_value = 0;
-	int the_result, retries, spintime;
+	int the_result, retries, spintime, mode_retries;
 	int sector_size;
 	Scsi_Request *SRpnt;
 
@@ -858,6 +858,105 @@
 		else
 			printk("ready\n");
 	}
+
+	mode_retries = 2;	/* make two attempts to change the cache type */
+
+ retry_mode_select:
+	retries = 3;
+	do {
+
+		memset((void *) &cmd[0], 0, 10);
+		cmd[0] = MODE_SENSE;
+		cmd[1] = (rscsi_disks[i].device->scsi_level <= SCSI_2) ?
+			 ((rscsi_disks[i].device->lun << 5) & 0xe0) : 0;
+		cmd[1] |= 0x08;	/* DBD */
+		cmd[2] = 0x08;	/* current values, cache page */
+		cmd[4] = 24;	/* allocation length */
+
+
+		memset((void *) buffer, 0, 24);
+		SRpnt->sr_cmd_len = 0;
+		SRpnt->sr_sense_buffer[0] = 0;
+		SRpnt->sr_sense_buffer[2] = 0;
+
+		SRpnt->sr_data_direction = SCSI_DATA_READ;
+		scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
+			    24, SD_TIMEOUT, MAX_RETRIES);
+
+		the_result = SRpnt->sr_result;
+		retries--;
+
+	} while (the_result && retries);
+
+	if (the_result) {
+		printk("%s : MODE SENSE failed.\n"
+		       "%s : status = %x, message = %02x, host = %d, driver = %02x \n",
+		       nbuff, nbuff,
+		       status_byte(the_result),
+		       msg_byte(the_result),
+		       host_byte(the_result),
+		       driver_byte(the_result)
+		    );
+		if (driver_byte(the_result) & DRIVER_SENSE)
+			print_req_sense("sd", SRpnt);
+		else
+			printk("%s : sense not available. \n", nbuff);
+	} else {
+		const char *types[] = { "write through", "none", "write back", "write back, no read (daft)" };
+		int ct = 0;
+
+		ct = (buffer[6] & 0x01 /* RCD */) | ((buffer[6] & 0x04 /* WCE */) >> 1);
+
+		printk("%s : checking drive cache: %s \n", nbuff, types[ct]);
+		if(ct != 0x0 && mode_retries-- == 0) {
+			printk("%s : FAILED to change cache to write back, continuing\n", nbuff);
+		}
+		else if(ct != 0x0) {
+			retries = 3;
+			buffer[6] &= (~0x05); /* clear RCD and WCE */
+			do {
+				memset((void *) &cmd[0], 0, 10);
+				cmd[0] = MODE_SELECT;
+				cmd[1] = (rscsi_disks[i].device->scsi_level <= SCSI_2) ?
+					((rscsi_disks[i].device->lun << 5) & 0xe0) : 0;
+				cmd[1] |= 0x10;	/* PF */
+				cmd[4] = 24;	/* allocation length */
+				
+				
+				SRpnt->sr_cmd_len = 0;
+				SRpnt->sr_sense_buffer[0] = 0;
+				SRpnt->sr_sense_buffer[2] = 0;
+				
+				SRpnt->sr_data_direction = SCSI_DATA_WRITE;
+				scsi_wait_req(SRpnt, (void *) cmd, (void *) buffer,
+					      24, SD_TIMEOUT, MAX_RETRIES);
+
+				the_result = SRpnt->sr_result;
+				retries--;
+
+			} while (the_result && retries);
+
+			if (the_result) {
+				printk("%s : MODE SELECT failed.\n"
+				       "%s : status = %x, message = %02x, host = %d, driver = %02x \n",
+				       nbuff, nbuff,
+				       status_byte(the_result),
+				       msg_byte(the_result),
+				       host_byte(the_result),
+				       driver_byte(the_result)
+				       );
+				if (driver_byte(the_result) & DRIVER_SENSE)
+					print_req_sense("sd", SRpnt);
+				else
+					printk("%s : sense not available. \n", nbuff);
+			} else {
+				printk("%s : changing drive cache to write through\n", nbuff);
+			}
+			goto retry_mode_select;
+		}
+		
+	}
+
 	retries = 3;
 	do {
 		cmd[0] = READ_CAPACITY;

  reply	other threads:[~2002-03-01  2:15 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 15:57 [PATCH] 2.4.x write barriers (updated for ext3) James Bottomley
2002-02-22 16:10 ` Chris Mason
2002-02-22 16:13 ` Stephen C. Tweedie
2002-02-22 17:36   ` James Bottomley
2002-02-22 18:14     ` Chris Mason
2002-02-28 15:36       ` James Bottomley
2002-02-28 15:55         ` Chris Mason
2002-02-28 17:58           ` Mike Anderson
2002-02-28 18:12           ` Chris Mason
2002-03-01  2:08             ` James Bottomley [this message]
2002-03-03 22:11         ` Daniel Phillips
2002-03-04  3:34           ` Chris Mason
2002-03-04  5:05             ` Daniel Phillips
2002-03-04 15:03               ` James Bottomley
2002-03-04 17:04                 ` Stephen C. Tweedie
2002-03-04 17:16                   ` Chris Mason
2002-03-04 18:05                     ` Stephen C. Tweedie
2002-03-04 18:28                       ` James Bottomley
2002-03-04 19:55                         ` Stephen C. Tweedie
2002-03-04 19:48                       ` Daniel Phillips
2002-03-04 19:57                         ` Stephen C. Tweedie
2002-03-04 21:06                           ` Daniel Phillips
2002-03-05 14:58                             ` Stephen C. Tweedie
2002-03-05  7:48                         ` Jens Axboe
2002-03-04 19:51                     ` Daniel Phillips
2002-03-05  7:42                       ` Jens Axboe
2002-03-04 17:35                   ` James Bottomley
2002-03-04 17:48                     ` Chris Mason
2002-03-04 18:11                       ` James Bottomley
2002-03-04 18:41                         ` Chris Mason
2002-03-04 21:34                         ` Stephen C. Tweedie
2002-03-04 18:09                     ` Stephen C. Tweedie
2002-03-04  8:19             ` Helge Hafting
2002-03-04 14:57             ` James Bottomley
2002-03-04 17:24               ` Chris Mason
2002-03-04 19:02                 ` Daniel Phillips
2002-03-05  7:22               ` Jeremy Higdon
2002-03-05 23:01                 ` Daniel Phillips
2002-03-04  4:21           ` Jeremy Higdon
2002-03-04  5:31             ` Daniel Phillips
2002-03-04  6:09               ` Jeremy Higdon
2002-03-04  7:57                 ` Daniel Phillips
2002-03-05  7:09                   ` Jeremy Higdon
2002-03-05 22:56                     ` Daniel Phillips
2002-03-04 16:52                 ` Stephen C. Tweedie
2002-03-04 18:15                   ` Daniel Phillips
2002-03-05  7:40                     ` Jens Axboe
2002-03-05 22:29                       ` Daniel Phillips
2002-03-12  7:01                         ` Jens Axboe
2002-03-10  5:24                   ` Douglas Gilbert
2002-03-11 11:13                     ` Kurt Garloff
2002-03-12  1:17                       ` GOTO Masanori
2002-03-12  6:58                       ` Jens Axboe
2002-03-13 22:37                         ` Peter Osterlund
2002-03-11 11:34                     ` Stephen C. Tweedie
2002-03-11 17:15                       ` James Bottomley
2002-03-04 14:48           ` James Bottomley
2002-03-06 13:59             ` Daniel Phillips
2002-03-06 14:34               ` James Bottomley
2002-02-25 10:57 ` Helge Hafting
2002-02-25 15:04   ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2002-03-01 15:26 Dieter Nützel
2002-03-01 16:00 ` James Bottomley
2002-02-21 23:30 Chris Mason
2002-02-22 14:19 ` Stephen C. Tweedie
2002-02-22 15:26   ` Chris Mason
2002-01-10  9:55 [ANNOUNCE] FUSE: Filesystem in Userspace 0.95 Miklos Szeredi
2002-01-13  3:10 ` Pavel Machek
2002-01-21 10:18   ` Miklos Szeredi
2002-01-23 10:47     ` Pavel Machek
2002-01-22 19:07 ` Daniel Phillips
2002-01-23  2:33   ` [Avfs] " Justin Mason
2002-01-23  5:26     ` Daniel Phillips

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=200203010208.g2128Qq01694@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=sct@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.