Here's a set of contest benchmarks using the osdl hardware comparing 2.5.60 to
59
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 79 93.7 0.0 0.0 1.00
2.5.60 2 79 94.9 0.0 0.0 1.00
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 76 97.4 0.0 0.0 0.96
2.5.60 2 75 98.7 0.0 0.0 0.95
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 92 81.5 29.7 17.4 1.16
2.5.60 2 93 80.6 30.5 17.2 1.18
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 98 80.6 2.0 5.1 1.24
2.5.60 2 99 78.8 1.0 4.0 1.25
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 102 74.5 1.0 3.9 1.29
2.5.60 2 101 76.2 1.0 5.0 1.28
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 152 50.0 34.1 13.1 1.92
2.5.60 2 139 54.7 29.0 12.1 1.76
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 89 84.3 11.2 5.6 1.13
2.5.60 2 90 83.3 10.8 5.5 1.14
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 101 77.2 6.5 5.0 1.28
2.5.60 2 103 74.8 6.2 6.8 1.30
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 95 80.0 0.0 6.3 1.20
2.5.60 2 95 80.0 0.0 6.3 1.20
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 95 82.1 52.7 2.1 1.20
2.5.60 2 98 79.6 53.0 2.0 1.24
well I don't see much difference. interestingly dbench_load wouldnt give me a
number because dbench never quite started - a whole swag of processes visible
but not doing anything (must be related to that oops I sent out with respect
to dbench running on mm10). Previous runs of dbench_load may have been
working because 0.6x releases of contest use dbench 4*num_cpus instead of
16*num_cpus which I am using in the development version.
Might give the cfq scheduler a go
Con
On Tue, Feb 11 2003, Con Kolivas wrote:
> Might give the cfq scheduler a go
That would be cool. I'm not expecting really good results, it's untuned
and all that. But would be interesting to see preliminary results, none
the less.
--
Jens Axboe
Con Kolivas <[email protected]> wrote:
>
> interestingly dbench_load wouldnt give me a number because dbench never
> quite started - a whole swag of processes visible but not doing anything
Signal problems...
What dbench is doing is:
- Install a SIGCONT handler
- fork N times, children drop into a pause()
- parent does kill(0, SIGCONT);
It appears that the SIGCONT is not causing the children to drop out of the
pause().
Changing it to SIGINT makes it work.
The tarball is at http://samba.org/ftp/tridge/dbench/dbench-2.0.tar.gz
Here's the relevant snippet:
static double create_procs(int nprocs, void (*fn)(struct child_struct * ))
{
int i, status;
int synccount;
signal(SIGCONT, sigcont);
start_timer();
synccount = 0;
if (nprocs < 1) {
fprintf(stderr,
"create %d procs? you must be kidding.\n",
nprocs);
return 1;
}
children = shm_setup(sizeof(struct child_struct)*nprocs);
if (!children) {
printf("Failed to setup shared memory\n");
return end_timer();
}
memset(children, 0, sizeof(*children)*nprocs);
for (i=0;i<nprocs;i++) {
children[i].id = i;
children[i].nprocs = nprocs;
}
for (i=0;i<nprocs;i++) {
if (fork() == 0) {
setbuffer(stdout, NULL, 0);
nb_setup(&children[i]);
children[i].status = getpid();
pause();
fn(&children[i]);
_exit(0);
}
}
do {
synccount = 0;
for (i=0;i<nprocs;i++) {
if (children[i].status) synccount++;
}
if (synccount == nprocs) break;
sleep(1);
} while (end_timer() < 30);
if (synccount != nprocs) {
printf("FAILED TO START %d CLIENTS (started %d)\n", nprocs, synccount);
return end_timer();
}
start_timer();
kill(0, SIGCONT);