Skip to contentSkip to conversation

MAX_READAHEAD gives doubled throuput

PATCH In review Roger Larsson 4 participants 6 messages Jul 28, 2001 – Jul 29, 2001

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 MAX_READAHEAD gives doubled throuput

Hi all,

Got wondering why simultaneous streaming is so much slower than normal...

Are there any reasons nowadays why we should not attempt to read ahead more than 31 pages at once?

31 pages equals 0.1 MB, it is read from the HD in 4 ms => very close to the average access times. Resulting in a maximum of half the possible speed.

With this patch copy and diff throughput are increased from 14 respective 11 MB/s to 27 and 28 !!!

I enable the profiling as well... (one printk warning fixed)

/RogerL

*******************************************
Patch prepared by: [email protected]

mm/filemap.c renamed from mm/filemap.c.orig +6 -8
@@ -744,10 +744,8 @@
 	return NULL;
 }
 
-#if 0
 #define PROFILE_READAHEAD
 #define DEBUG_READAHEAD
-#endif
 
 /*
  * Read-ahead profiling information
@@ -791,13 +789,13 @@
 		}
 
 		printk("Readahead average:  max=%ld, len=%ld, win=%ld, async=%ld%%\n",
-			total_ramax/total_reada,
-			total_ralen/total_reada,
-			total_rawin/total_reada,
-			(total_async*100)/total_reada);
+		       total_ramax/total_reada,
+		       total_ralen/total_reada,
+		       total_rawin/total_reada,
+		       (total_async*100)/total_reada);
 #ifdef DEBUG_READAHEAD
-		printk("Readahead snapshot: max=%ld, len=%ld, win=%ld, raend=%Ld\n",
-			filp->f_ramax, filp->f_ralen, filp->f_rawin, filp->f_raend);
+		printk("Readahead snapshot: max=%ld, len=%ld, win=%ld, raend=%ld\n",
+		       filp->f_ramax, filp->f_ralen, filp->f_rawin, filp->f_raend);
 #endif
 
 		total_reada	= 0;
include/linux/blkdev.h renamed from include/linux/blkdev.h.orig +1 -1
@@ -184,7 +184,7 @@
 #define PageAlignSize(size) (((size) + PAGE_SIZE -1) & PAGE_MASK)
 
 /* read-ahead in pages.. */
-#define MAX_READAHEAD	31
+#define MAX_READAHEAD	511
 #define MIN_READAHEAD	3
 
 #define blkdev_entry_to_request(entry) list_entry((entry), struct request, 

queue)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

#1 lore raw
Quoted 8 lines · Roger Larsson

Hi all,

Got wondering why simultaneous streaming is so much slower than normal...

Are there any reasons nowadays why we should not attempt to read ahead more than 31 pages at once?

Quoted 6 lines

31 pages equals 0.1 MB, it is read from the HD in 4 ms => very close to the average access times. Resulting in a maximum of half the possible speed.

With this patch copy and diff throughput are increased from 14 respective 11 MB/s to 27 and 28 !!!

Wheeeeee! Out of interest, what are the numbers for 2.4.7 vs 2.4.8-pre1 ?

--
Daniel

#2 lore raw
In reply to Roger Larsson
Quoted 4 lines · Daniel Phillips

[- - -]
Wheeeeee! Out of interest, what are the numbers for 2.4.7 vs 2.4.8-pre1 ?

Ok, time for a table... (all but dbench are best of 3 with source and destination files bigger than memory, dbench is only run once)

write copy read diff dbench
2.4.0 32.2 16.4 29.7 15.4 32.9
2.4.4 33.2 15.8 29.8 - -
2.4.6-pre1+s-irq 33.0 15.6 29.5 11.0 38.9
2.4.7 32.8 16.1 29.4 10.9 32.9
2.4.8-pre1 33.2 16.4 29.5 11.2 26.1
2.4.8-pre1+MRA 30.3 28.3 29.8 28.4 34.8

/RogerL
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/

#3 lore raw
In reply to Roger Larsson
Quoted 8 lines · Roger Larsson

Hi all,

Got wondering why simultaneous streaming is so much slower than normal...

Are there any reasons nowadays why we should not attempt to read ahead more than 31 pages at once?

Quoted 8 lines

31 pages equals 0.1 MB, it is read from the HD in 4 ms => very close to the average access times. Resulting in a maximum of half the possible speed.

With this patch copy and diff throughput are increased from 14 respective 11 MB/s to 27 and 28 !!!

I enable the profiling as well... (one printk warning fixed)

It doesn't make any difference here.

Dual 500MHz x86, 20 meg/sec IDE, 512 megs of RAM, kernel 2.4.7. Diffing two kernel trees is 129 seconds without patch, 130 with. Increasing MIN_READAHEAD to 31 as well saved eight seconds or so.

What kernel did you test with, and what are the specs for the test machine? Are your disks performing internal readahead? If so, how much, and how large is the on-disk cache?

/dev/hdf:

 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)

geometry = 5606/255/63, sectors = 90069840, start = 0
mnm:/home/akpm> 0 hdparm -I /dev/hdf

/dev/hdf:

Model=BI-MTDAL3-7040 5 , FwRev=XTO66AA0, SerialNo= Y EMMYQG9424
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=90069840 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 *udma3 udma4 udma5

#4 lore raw
In reply to Roger Larsson
Quoted 15 lines · Andrew Morton
Quoted 14 lines · Roger Larsson

Hi all,

Got wondering why simultaneous streaming is so much slower than normal...

Are there any reasons nowadays why we should not attempt to read ahead more than 31 pages at once?

31 pages equals 0.1 MB, it is read from the HD in 4 ms => very close to the average access times. Resulting in a maximum of half the possible speed.

With this patch copy and diff throughput are increased from 14 respective 11 MB/s to 27 and 28 !!!

Quoted 8 lines
Quoted 1 line

I enable the profiling as well... (one printk warning fixed)

It doesn't make any difference here.

Dual 500MHz x86, 20 meg/sec IDE, 512 megs of RAM, kernel 2.4.7. Diffing two kernel trees is 129 seconds without patch, 130 with. Increasing MIN_READAHEAD to 31 as well saved eight seconds or so.

Do not diff the trees - diff the tars!
(most files in the tree is so small that they fit well in the 31 pages) Even the tars might be to small for a second run (fits in memory...)

Quoted 15 lines

What kernel did you test with, and what are the specs for the test machine? Are your disks performing internal readahead? If so, how much, and how large is the on-disk cache?

/dev/hdf:

 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
Quoted 3 lines

geometry = 5606/255/63, sectors = 90069840, start = 0
mnm:/home/akpm> 0 hdparm -I /dev/hdf

/dev/hda:

 multcount    = 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)

geometry = 5606/255/63, sectors = 90069840, start = 0

ok, so I did not have 32 bit nor unmaskirq turned on... should it matter?

Quoted 10 lines

/dev/hdf:

Model=BI-MTDAL3-7040 5 , FwRev=XTO66AA0, SerialNo=

      Y EMMYQG9424 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=90069840 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 *udma3 udma4 udma5

/dev/hda:

Model=BI-MTDAL3-7040 5 , FwRev=XTO66AA0, SerialNo=
Y EMMYQM0073
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=90069840 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5
Kernel Drive Geometry LogicalCHS=5606/255/63 PhysicalCHS=22075/16/255

Signature · 7 lines
Roger Larsson
Skelleftea
Sweden
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/
#5 lore raw
In reply to Roger Larsson
Quoted 2 lines · Roger Larsson

With this patch copy and diff throughput are increased from 14 respective 11 MB/s to 27 and 28 !!!

Alan's kernel has max-readahead as a /proc/sys/vm parameter.

Signature · 1 line
Michael.