linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch] zero-bounce block highmem I/O, #13
@ 2001-08-27 10:37 Jens Axboe
  2001-08-28 10:26 ` Christoph Rohland
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2001-08-27 10:37 UTC (permalink / raw)
  To: Linux Kernel; +Cc: David S. Miller

Hi,

I've uploaded a new version. Changes since last time includes the
following:

- Merge BIO_CONTIG from 2.5 bio patches to unify testing of contigious
  buffer heads (BH_CONTIG in 2.4 tree) (me)

- cciss, cpqarray, and ide-dma wrongly used 0 for lastdataend in segment
  merging, which is wrong since 0 is a valid physical address. A case of
  s/NULL/0 substition when changing from virtual to physical tests.
  (davem)

- cciss/cpqarray - drop my_sg list, just use the kernel supplied
  scatterlist. my_sg used unsigned short for length, which is too small.
  (pointed out by davem, fixed by me)

- cciss/cpqarray - rewrite loop-until-empty in request queueing. (me)

- BLK_BOUNCE_ANY was b0rken, the ->bounce_page would wrap and thus not
  work. (pointed davem out by davem, fixed by me -- temporarily, will
  change to test for highest page instead in next version)

- Always use 64-bit type for BLK_BOUNCE_ANY (davem)

- IPS must check number of segments mapped by pci_map_sg instead of
  using the SCSI supplied sg count. (pointed out by davem, fixed by me).
  IPS still has some highmem fixes pending.

2.4.9 version is here:

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.9/block-highmem-all-13

2.4.8-ac12 version is here:

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.8-ac12/block-highmem-all-13-ac12

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-27 10:37 [patch] zero-bounce block highmem I/O, #13 Jens Axboe
@ 2001-08-28 10:26 ` Christoph Rohland
  2001-08-28 10:41   ` Jens Axboe
  2001-08-28 10:55   ` Jens Axboe
  0 siblings, 2 replies; 9+ messages in thread
From: Christoph Rohland @ 2001-08-28 10:26 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Linux Kernel, David S. Miller

Hi Jens,

I tested both #11 and #13 on my 8GB machine with sym53c8xx. The
initialization of a SAP DB database takes 20 minutes with 2.4.9 and
with 2.4.9+b13 it took nearly 2.5 hours :-(

Greetings
		Christoph



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 10:26 ` Christoph Rohland
@ 2001-08-28 10:41   ` Jens Axboe
  2001-08-28 10:55   ` Jens Axboe
  1 sibling, 0 replies; 9+ messages in thread
From: Jens Axboe @ 2001-08-28 10:41 UTC (permalink / raw)
  To: Christoph Rohland; +Cc: Linux Kernel, David S. Miller

On Tue, Aug 28 2001, Christoph Rohland wrote:
> Hi Jens,
> 
> I tested both #11 and #13 on my 8GB machine with sym53c8xx. The
> initialization of a SAP DB database takes 20 minutes with 2.4.9 and
> with 2.4.9+b13 it took nearly 2.5 hours :-(

Hmm that sounds _very_ strange indeed. What does the controller + disk
detection info look like?

Could you attach vmstat 1 info for pristine and b13 so I can compare the
two and get a clue as to what is going on? Thanks.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 10:26 ` Christoph Rohland
  2001-08-28 10:41   ` Jens Axboe
@ 2001-08-28 10:55   ` Jens Axboe
  2001-08-28 11:41     ` Jens Axboe
       [not found]     ` <m3elpw5smc.fsf@linux.local>
  1 sibling, 2 replies; 9+ messages in thread
From: Jens Axboe @ 2001-08-28 10:55 UTC (permalink / raw)
  To: Christoph Rohland; +Cc: Linux Kernel, David S. Miller

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

On Tue, Aug 28 2001, Christoph Rohland wrote:
> Hi Jens,
> 
> I tested both #11 and #13 on my 8GB machine with sym53c8xx. The
> initialization of a SAP DB database takes 20 minutes with 2.4.9 and
> with 2.4.9+b13 it took nearly 2.5 hours :-(

DaveM hinted that it's probably the bounce test failing, so it's
bouncing all the time. That would explain the much worse performance.
Could you try with this incremental patch on top of b13 for 2.4.9? I
still want to see the boot detection info, btw.

THanks!

-- 
Jens Axboe


[-- Attachment #2: block-highmem-all-13-any-1 --]
[-- Type: text/plain, Size: 2721 bytes --]

diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- /opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c	Wed Jul 11 18:31:44 2001
+++ linux/arch/i386/kernel/setup.c	Mon Aug 27 15:03:14 2001
@@ -152,6 +152,8 @@
 static int disable_x86_serial_nr __initdata = 1;
 static int disable_x86_fxsr __initdata = 0;
 
+unsigned long max_pfn;
+
 /*
  * This is set up by the setup-routine at boot-time
  */
@@ -768,7 +770,7 @@
 void __init setup_arch(char **cmdline_p)
 {
 	unsigned long bootmap_size, low_mem_size;
-	unsigned long start_pfn, max_pfn, max_low_pfn;
+	unsigned long start_pfn, max_low_pfn;
 	int i;
 
 #ifdef CONFIG_VISWS
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
--- /opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c	Tue Aug 28 12:51:56 2001
+++ linux/drivers/block/ll_rw_blk.c	Mon Aug 27 15:03:42 2001
@@ -125,7 +125,7 @@
  */
 static int queue_nr_requests, batch_requests;
 
-unsigned long blk_max_low_pfn;
+unsigned long blk_max_low_pfn, blk_max_pfn;
 
 static inline int get_max_sectors(kdev_t dev)
 {
@@ -1207,6 +1207,7 @@
 	printk("block: %d slots per queue, batch=%d\n", queue_nr_requests, batch_requests);
 
 	blk_max_low_pfn = max_low_pfn;
+	blk_max_pfn = max_pfn;
 
 #ifdef CONFIG_AMIGA_Z2RAM
 	z2_init();
@@ -1328,4 +1329,5 @@
 EXPORT_SYMBOL(generic_unplug_device);
 EXPORT_SYMBOL(blk_queue_bounce_limit);
 EXPORT_SYMBOL(blk_max_low_pfn);
+EXPORT_SYMBOL(blk_max_pfn);
 EXPORT_SYMBOL(blk_seg_merge_ok);
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/include/linux/blkdev.h linux/include/linux/blkdev.h
--- /opt/kernel/linux-2.4.9/include/linux/blkdev.h	Tue Aug 28 12:51:56 2001
+++ linux/include/linux/blkdev.h	Mon Aug 27 14:58:02 2001
@@ -126,10 +126,10 @@
 	wait_queue_head_t	wait_for_request;
 };
 
-extern unsigned long blk_max_low_pfn;
+extern unsigned long blk_max_low_pfn, blk_max_pfn;
 
 #define BLK_BOUNCE_HIGH		(blk_max_low_pfn * PAGE_SIZE)
-#define BLK_BOUNCE_ANY		(~(unsigned long long) 0)
+#define BLK_BOUNCE_ANY		(blk_max_pfn * PAGE_SIZE)
 
 extern void blk_queue_bounce_limit(request_queue_t *, dma64_addr_t);
 
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/include/linux/bootmem.h linux/include/linux/bootmem.h
--- /opt/kernel/linux-2.4.9/include/linux/bootmem.h	Wed Aug 15 23:22:13 2001
+++ linux/include/linux/bootmem.h	Mon Aug 27 14:53:47 2001
@@ -18,6 +18,11 @@
 extern unsigned long min_low_pfn;
 
 /*
+ * highest page
+ */
+extern unsigned long max_pfn;
+
+/*
  * node_bootmem_map is a map pointer - the bits represent all physical 
  * memory pages (including holes) on the node.
  */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 10:55   ` Jens Axboe
@ 2001-08-28 11:41     ` Jens Axboe
  2001-08-28 12:16       ` Christoph Rohland
       [not found]     ` <m3elpw5smc.fsf@linux.local>
  1 sibling, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2001-08-28 11:41 UTC (permalink / raw)
  To: Christoph Rohland; +Cc: Linux Kernel, David S. Miller

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

On Tue, Aug 28 2001, Jens Axboe wrote:
> On Tue, Aug 28 2001, Christoph Rohland wrote:
> > Hi Jens,
> > 
> > I tested both #11 and #13 on my 8GB machine with sym53c8xx. The
> > initialization of a SAP DB database takes 20 minutes with 2.4.9 and
> > with 2.4.9+b13 it took nearly 2.5 hours :-(
> 
> DaveM hinted that it's probably the bounce test failing, so it's
> bouncing all the time. That would explain the much worse performance.
> Could you try with this incremental patch on top of b13 for 2.4.9? I
> still want to see the boot detection info, btw.
> 
> THanks!

Ok found the bug -- SCSI was accidentally using blk_seg_merge_ok when it
just wanted to test if we were crossing a 4GB physical address boundary
or not. Doh! Attached incremental patch should fix the SCSI performance
issue. I'm testing right now...

-- 
Jens Axboe


[-- Attachment #2: block-highmem-all-13-any-2 --]
[-- Type: text/plain, Size: 4174 bytes --]

diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- /opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c	Wed Jul 11 18:31:44 2001
+++ linux/arch/i386/kernel/setup.c	Mon Aug 27 15:03:14 2001
@@ -152,6 +152,8 @@
 static int disable_x86_serial_nr __initdata = 1;
 static int disable_x86_fxsr __initdata = 0;
 
+unsigned long max_pfn;
+
 /*
  * This is set up by the setup-routine at boot-time
  */
@@ -768,7 +770,7 @@
 void __init setup_arch(char **cmdline_p)
 {
 	unsigned long bootmap_size, low_mem_size;
-	unsigned long start_pfn, max_pfn, max_low_pfn;
+	unsigned long start_pfn, max_low_pfn;
 	int i;
 
 #ifdef CONFIG_VISWS
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
--- /opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c	Tue Aug 28 12:51:56 2001
+++ linux/drivers/block/ll_rw_blk.c	Tue Aug 28 13:26:33 2001
@@ -125,7 +125,7 @@
  */
 static int queue_nr_requests, batch_requests;
 
-unsigned long blk_max_low_pfn;
+unsigned long blk_max_low_pfn, blk_max_pfn;
 
 static inline int get_max_sectors(kdev_t dev)
 {
@@ -292,8 +292,7 @@
 	if (!BH_CONTIG(bh, nxt))
 		return 0;
 
-	if ((bh_phys(bh) | 0xffffffff) ==
-	    ((bh_phys(nxt) + nxt->b_size - 1) | 0xffffffff))
+	if (BH_PHYS_4G(bh, nxt))
 		return 1;
 
 	return 0;
@@ -1207,6 +1206,7 @@
 	printk("block: %d slots per queue, batch=%d\n", queue_nr_requests, batch_requests);
 
 	blk_max_low_pfn = max_low_pfn;
+	blk_max_pfn = max_pfn;
 
 #ifdef CONFIG_AMIGA_Z2RAM
 	z2_init();
@@ -1328,4 +1328,5 @@
 EXPORT_SYMBOL(generic_unplug_device);
 EXPORT_SYMBOL(blk_queue_bounce_limit);
 EXPORT_SYMBOL(blk_max_low_pfn);
+EXPORT_SYMBOL(blk_max_pfn);
 EXPORT_SYMBOL(blk_seg_merge_ok);
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/drivers/scsi/scsi_merge.c linux/drivers/scsi/scsi_merge.c
--- /opt/kernel/linux-2.4.9/drivers/scsi/scsi_merge.c	Tue Aug 28 12:51:56 2001
+++ linux/drivers/scsi/scsi_merge.c	Tue Aug 28 13:35:07 2001
@@ -417,7 +417,7 @@
 
 	if ((req->nr_sectors + (bh->b_size >> 9)) > SHpnt->max_sectors)
 		return 0;
-	else if (!blk_seg_merge_ok(q, req->bhtail, bh))
+	else if (!BH_PHYS_4G(req->bhtail, bh))
 		return 0;
 
 	if (use_clustering) {
@@ -475,7 +475,7 @@
 
 	if ((req->nr_sectors + (bh->b_size >> 9)) > SHpnt->max_sectors)
 		return 0;
-	else if (!blk_seg_merge_ok(q, bh, req->bh))
+	else if (!BH_PHYS_4G(bh, req->bh))
 		return 0;
 
 	if (use_clustering) {
@@ -610,7 +610,7 @@
 	SDpnt = (Scsi_Device *) q->queuedata;
 	SHpnt = SDpnt->host;
 
-	if (!blk_seg_merge_ok(q, req->bhtail, next->bh))
+	if (!BH_PHYS_4G(req->bhtail, next->bh))
 		return 0;
 
 #ifdef DMA_CHUNK_SIZE
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/include/linux/blkdev.h linux/include/linux/blkdev.h
--- /opt/kernel/linux-2.4.9/include/linux/blkdev.h	Tue Aug 28 12:51:56 2001
+++ linux/include/linux/blkdev.h	Tue Aug 28 13:27:42 2001
@@ -126,10 +126,10 @@
 	wait_queue_head_t	wait_for_request;
 };
 
-extern unsigned long blk_max_low_pfn;
+extern unsigned long blk_max_low_pfn, blk_max_pfn;
 
 #define BLK_BOUNCE_HIGH		(blk_max_low_pfn * PAGE_SIZE)
-#define BLK_BOUNCE_ANY		(~(unsigned long long) 0)
+#define BLK_BOUNCE_ANY		(blk_max_pfn * PAGE_SIZE)
 
 extern void blk_queue_bounce_limit(request_queue_t *, dma64_addr_t);
 
@@ -150,6 +150,7 @@
 #define bh_phys(bh)		(page_to_phys((bh)->b_page) + bh_offset((bh)))
 
 #define BH_CONTIG(b1, b2)	(bh_phys((b1)) + (b1)->b_size == bh_phys((b2)))
+#define BH_PHYS_4G(b1, b2)	((bh_phys((b1)) | 0xffffffff) == ((bh_phys((b2)) + (b2)->b_size - 1) | 0xffffffff))
 
 struct blk_dev_struct {
 	/*
diff -ur --exclude-from /home/axboe/exclude /opt/kernel/linux-2.4.9/include/linux/bootmem.h linux/include/linux/bootmem.h
--- /opt/kernel/linux-2.4.9/include/linux/bootmem.h	Wed Aug 15 23:22:13 2001
+++ linux/include/linux/bootmem.h	Mon Aug 27 14:53:47 2001
@@ -18,6 +18,11 @@
 extern unsigned long min_low_pfn;
 
 /*
+ * highest page
+ */
+extern unsigned long max_pfn;
+
+/*
  * node_bootmem_map is a map pointer - the bits represent all physical 
  * memory pages (including holes) on the node.
  */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
       [not found]     ` <m3elpw5smc.fsf@linux.local>
@ 2001-08-28 11:45       ` Jens Axboe
  0 siblings, 0 replies; 9+ messages in thread
From: Jens Axboe @ 2001-08-28 11:45 UTC (permalink / raw)
  To: Christoph Rohland; +Cc: Linux Kernel, David S. Miller

On Tue, Aug 28 2001, Christoph Rohland wrote:
> Hi Jens,
> 
> On Tue, 28 Aug 2001, Jens Axboe wrote:
> > On Tue, Aug 28 2001, Christoph Rohland wrote:
> >> Hi Jens,
> >> 
> >> I tested both #11 and #13 on my 8GB machine with sym53c8xx. The
> >> initialization of a SAP DB database takes 20 minutes with 2.4.9 and
> >> with 2.4.9+b13 it took nearly 2.5 hours :-(
> > 
> > DaveM hinted that it's probably the bounce test failing, so it's
> > bouncing all the time. That would explain the much worse
> > performance.  Could you try with this incremental patch on top of
> > b13 for 2.4.9? I still want to see the boot detection info, btw.
> 
> Apparently it did not help. See attachments: vmstat was 'vmstat
> 5'. The b13 output is only the end. The b13-1 is still running but the
> blockout rate is again low. So I do not wait another 2 hours...

Nope fine, no need to wait :-)

The -2 patch I sent should fix it, performance looks good here (just a
5min test run to verify).

What happened was that we would fall back to single segment requests all
the time. A real performance killer for SCSI.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 11:41     ` Jens Axboe
@ 2001-08-28 12:16       ` Christoph Rohland
  2001-08-28 12:43         ` Jens Axboe
  0 siblings, 1 reply; 9+ messages in thread
From: Christoph Rohland @ 2001-08-28 12:16 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Linux Kernel, David S. Miller

Hi Jens,

On Tue, 28 Aug 2001, Jens Axboe wrote:
> Ok found the bug -- SCSI was accidentally using blk_seg_merge_ok
> when it just wanted to test if we were crossing a 4GB physical
> address boundary or not. Doh! Attached incremental patch should fix
> the SCSI performance issue. I'm testing right now...

Yup, performance is back to 2.4.9 level. But I do not see an
improvement.

I will now do a database import.

Greetings
		Christoph



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 12:16       ` Christoph Rohland
@ 2001-08-28 12:43         ` Jens Axboe
  2001-08-28 15:59           ` Christoph Rohland
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2001-08-28 12:43 UTC (permalink / raw)
  To: Christoph Rohland; +Cc: Linux Kernel, David S. Miller

On Tue, Aug 28 2001, Christoph Rohland wrote:
> Hi Jens,
> 
> On Tue, 28 Aug 2001, Jens Axboe wrote:
> > Ok found the bug -- SCSI was accidentally using blk_seg_merge_ok
> > when it just wanted to test if we were crossing a 4GB physical
> > address boundary or not. Doh! Attached incremental patch should fix
> > the SCSI performance issue. I'm testing right now...
> 
> Yup, performance is back to 2.4.9 level. But I do not see an
> improvement.
> 
> I will now do a database import.

Of course it depends on the type of work load how big an improvement you
see. How much RAM is in the machine?

It would be interesting to see profiles of stock + highmem kernels.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] zero-bounce block highmem I/O, #13
  2001-08-28 12:43         ` Jens Axboe
@ 2001-08-28 15:59           ` Christoph Rohland
  0 siblings, 0 replies; 9+ messages in thread
From: Christoph Rohland @ 2001-08-28 15:59 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Linux Kernel, David S. Miller

Hi Jens,

On Tue, 28 Aug 2001, Jens Axboe wrote:
> Of course it depends on the type of work load how big an improvement
> you see. How much RAM is in the machine?

8GB

> It would be interesting to see profiles of stock + highmem kernels.

I just started the whole installation with profiling enabled. I will
send you date earliest tomorrow evening.

Greetings
		Christoph



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2001-08-28 16:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-27 10:37 [patch] zero-bounce block highmem I/O, #13 Jens Axboe
2001-08-28 10:26 ` Christoph Rohland
2001-08-28 10:41   ` Jens Axboe
2001-08-28 10:55   ` Jens Axboe
2001-08-28 11:41     ` Jens Axboe
2001-08-28 12:16       ` Christoph Rohland
2001-08-28 12:43         ` Jens Axboe
2001-08-28 15:59           ` Christoph Rohland
     [not found]     ` <m3elpw5smc.fsf@linux.local>
2001-08-28 11:45       ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).