zero-bounce block highmem I/O, #13
Subsystems (2)
PATCH 1/1 zero-bounce block highmem I/O, #13
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
Signature · 1 line
Jens Axboe
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
Quoted 5 lines · Christoph Rohland
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.
Signature · 1 line
Jens Axboe
Quoted 5 lines · Christoph Rohland
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!
Signature · 1 line
Jens Axboe
arch/i386/kernel/setup.c renamed from opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c +3 -1
@@ -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
drivers/block/ll_rw_blk.c renamed from opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c +3 -1
@@ -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);
include/linux/blkdev.h renamed from opt/kernel/linux-2.4.9/include/linux/blkdev.h +2 -2
@@ -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 );
include/linux/bootmem.h renamed from opt/kernel/linux-2.4.9/include/linux/bootmem.h +5 -0
@@ -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. */
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Christoph Rohland
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 :-(
Quoted 6 lines
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...
Signature · 1 line
Jens Axboe
arch/i386/kernel/setup.c renamed from opt/kernel/linux-2.4.9/arch/i386/kernel/setup.c +3 -1
@@ -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
drivers/block/ll_rw_blk.c renamed from opt/kernel/linux-2.4.9/drivers/block/ll_rw_blk.c +4 -3
@@ -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);
drivers/scsi/scsi_merge.c renamed from opt/kernel/linux-2.4.9/drivers/scsi/scsi_merge.c +3 -3
@@ -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
include/linux/blkdev.h renamed from opt/kernel/linux-2.4.9/include/linux/blkdev.h +3 -2
@@ -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 {/*
include/linux/bootmem.h renamed from opt/kernel/linux-2.4.9/include/linux/bootmem.h +5 -0
@@ -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. */
Quoted 10 lines · Christoph Rohland
Hi Jens,
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Christoph Rohland
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 :-(
Quoted 8 lines
Quoted 4 lines
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.
Signature · 1 line
Jens Axboe
Hi Jens,
Quoted 4 lines · Jens Axboe
Ok found the bug -- SCSI was accidentally using
blk_seg_merge_okwhen 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
Quoted 8 lines · Christoph Rohland
Hi Jens,
Quoted 4 lines · Jens Axboe
Ok found the bug -- SCSI was accidentally using
blk_seg_merge_okwhen 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...
Quoted 4 lines
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.
Signature · 1 line
Jens Axboe
Hi Jens,
Quoted 2 lines · Jens Axboe
Of course it depends on the type of work load how big an improvement you see. How much RAM is in the machine?
8GB
Quoted 1 line
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