re-aim - 2.5.69, -mm6

re-aim - 2.5.69, -mm6

[Cliff White]

This is the result of running the Reaim test against the 
2.5.69 and 2.5.69-mm6 kernels. The -mm kernels are a bit
slower, and i'm wondering if i'm missing a tuning knob somewhere..
advice appreciated.

Re-aim is a rework of the AIM suite. (locations below)

Two data points i look at-
1. Maximum jobs per minute  
2. Number of children when Jobs/second/child less than 1.0. 
	(convergence)

Load is the new_dbase load. (AIM7 dbase load with less synch IO)
System is a 4-CPU PIII with 4GB of physical
memory, test used 4 SCSI disks on a qlogicfc adapter. 
Test is run with two different convergence methods, 3 runs each.
Peak load is the average of 3 runs, i pick the best results
regardless of convergence method. 

Kernel                Peak Load
2.5.69 - base         5216.68 Jobs/Minute
2.5.69-mm6(AS)        4963.36 JPM
2.5.69-mm6(deadline)  4966.71 JPM
2.5.69-mm7(AS)        4966.86 JPM

Load when JPS/child < 1.0 (c_ times are total for all children)
Average of six runs

Kernel             Children  JPM       RunTime  c_utime  c_systime

2.5.69 - base      88         5185.88  104.87   376.01   40.28
2.5.69-mm6(AS)     84         4894.73  106.08   374.91   45.54  
2.5.69-mm6(deadln) 84         4858.36  106.90   376.55   46.41
2.5.69-mm7(AS)     84         4853.80  106.95   378.02   46.26


Attempting a second pass of -mm7 caused the hang reported earlier. 
cliffw
OSDL

report details and profile data at:
http://www.osdl.org/archive/cliffw/reaim 

Reaim code at:
http://sourceforge.net/projects/re-aim-7
or
bk://bk.osdl.org/aimrework

Re: re-aim - 2.5.69, -mm6

[Andrew Morton]

Cliff White <cliffw@osdl.org> wrote:
>
>  This is the result of running the Reaim test against the 
>  2.5.69 and 2.5.69-mm6 kernels. The -mm kernels are a bit
>  slower, and i'm wondering if i'm missing a tuning knob somewhere..
>  advice appreciated.

I can look into the slowdown.  Could you please tell me exactly how you are
invoking the benchmark?  Show me what commands you're using, so I can do
exactly the same thing.

>  Attempting a second pass of -mm7 caused the hang reported earlier. 

I have a bad feeling I won't be able to reproduce this.  If you could
capture the output from a sysrq-T (or "echo t > /proc/sysrq-trigger") then
that would help a lot.

It could be a hole in the new dynamic request allocation code, or a driver
problem.  Or something else.

Re: re-aim - 2.5.69, -mm6

[Cliff White]

> Cliff White <cliffw@osdl.org> wrote:
> >
> >  This is the result of running the Reaim test against the 
> >  2.5.69 and 2.5.69-mm6 kernels. The -mm kernels are a bit
> >  slower, and i'm wondering if i'm missing a tuning knob somewhere..
> >  advice appreciated.
> 
> I can look into the slowdown.  Could you please tell me exactly how you are
> invoking the benchmark?  Show me what commands you're using, so I can do
> exactly the same thing.

For these runs, i'm using the STP wrap.sh - you can get that kit from stp cvs 
if you need.
The wrap.sh does the disk setup and a few other things,then invokes the test. 

The two runs are done like this -> (4 cpu machine)
./reaim -s4 -x -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
maxjobs convergence
./reaim -s4 -q -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
'quick' convergence

stp.config has the poolsizes and path for disk directories:
FILESIZE 80k
POOLSIZE 1024k
DISKDIR /mnt/disk1
DISKDIR /mnt/disk2
DISKDIR /mnt/disk3
DISKDIR /mnt/disk4

Options: 
the -b surpresseses stdout and creates an html version of the report. - this 
is for STP and
not necessary. 
the -r3 runs the test three times
-t turns off the adaptive increment

cliffw

> 
> >  Attempting a second pass of -mm7 caused the hang reported earlier. 
> 
> I have a bad feeling I won't be able to reproduce this.  If you could
> capture the output from a sysrq-T (or "echo t > /proc/sysrq-trigger") then
> that would help a lot.
> 
> It could be a hole in the new dynamic request allocation code, or a driver
> problem.  Or something else.
> 

Re: re-aim - 2.5.69, -mm6

[Andrew Morton]

Cliff White <cliffw@osdl.org> wrote:
>
> The two runs are done like this -> (4 cpu machine)
>  ./reaim -s4 -x -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
>  maxjobs convergence
>  ./reaim -s4 -q -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
>  'quick' convergence
> 
>  stp.config has the poolsizes and path for disk directories:
>  FILESIZE 80k
>  POOLSIZE 1024k
>  DISKDIR /mnt/disk1
>  DISKDIR /mnt/disk2
>  DISKDIR /mnt/disk3
>  DISKDIR /mnt/disk4

Well I spent a few hours running this on the quad xeon (aic7xxx).

There were no hangs, and there was no appreciable performance difference
between 2.5.69, 2.6.69-mm7++ with AS and 2.5.69-mm7++ with deadline.

Please confirm that the hang only happened with the anticipatory scheduler?

It could require a particular device driver to reproduce.  Please see if
you can generate that sysrq-T output.  Also if you can try a different
device driver sometime that would be interesting.  There seem to be several
alternate ISP drivers around - the feral driver perhaps, and the new one in
the linux-scsi tree.

Re: re-aim - 2.5.69, -mm6

[Cliff White]

> Cliff White <cliffw@osdl.org> wrote:
> >
> > The two runs are done like this -> (4 cpu machine)
> >  ./reaim -s4 -x -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
> >  maxjobs convergence
> >  ./reaim -s4 -q -t -i4 -f workfile.new_dbase -r3 -b -lstp.config -> for the 
> >  'quick' convergence
> > 
> >  stp.config has the poolsizes and path for disk directories:
> >  FILESIZE 80k
> >  POOLSIZE 1024k
> >  DISKDIR /mnt/disk1
> >  DISKDIR /mnt/disk2
> >  DISKDIR /mnt/disk3
> >  DISKDIR /mnt/disk4
> 
> Well I spent a few hours running this on the quad xeon (aic7xxx).
> 
> There were no hangs, and there was no appreciable performance difference
> between 2.5.69, 2.6.69-mm7++ with AS and 2.5.69-mm7++ with deadline.
> 
> Please confirm that the hang only happened with the anticipatory scheduler?
Yes. Those are the only hangs. 
> 
> It could require a particular device driver to reproduce.  Please see if
> you can generate that sysrq-T output.  Also if you can try a different
> device driver sometime that would be interesting.  There seem to be several
> alternate ISP drivers around - the feral driver perhaps, and the new one in
> the linux-scsi tree.

Okay - i have been using qlogicfc,but there are others.. 
OSDL is moving this weekend, so it'll be a bit before i have a machine up.
cliffw

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>