Ah, thanks.
> Could it be a disk driver issue? Maybe 2.4 has some IDE
> enhancements that aren't in 2.5 yet.
Well I tested the AIM7 dbase workload yesterday on 256MB IDE. 2.4 and 2.5
have the same throughput, down to a fraction of one percent. The entire
working set appeared to be around 200MB so there was no reading from disk at
all. Just 25 minutes of trickling out very slow O_SYNC writes. The thing is
dominated by disk seek time.
> Here is AIM7 dbase on quad Xeon with 3.75 GB ram over ext2:
>
> AIM7 dbase workload
> kernel Tasks Jobs/Min Real CPU
> 2.5.62-mm2 32 555.9 342.0 155.2
> 2.4.21-pre4aa1 32 554.4 342.8 142.3
> 2.4.21-pre4aa3 32 551.9 344.4 149.6
> 2.4.21-pre4-ac3 32 473.8 401.2 147.7
> 2.5.62 32 473.6 401.3 148.2
> 2.5.63-mjb2 32 472.5 402.3 161.5
> 2.5.63 32 471.6 403.1 153.1
> 2.2.24-rc3 32 431.9 440.1 165.7
>
> 2.5.62-mm2 has the feral driver. aa has the QLogic 6.x driver.
Well if there is any difference in drive caching policy then one would expect
to see large differences. Using writeback caching in the disk (which is
considered cheating) would speed things up. But I'd be surprised if
2.5-vs-2.4 IDE affected the drive's caching policy.
> Those two kernels rule AIM7 dbase and fserver on quad Xeon with
> QLA2200. I tested earlier 2.5 and aa with/without the newer
> QLogic drivers. It was _the_most_important_ factor for AIM7
> dbase and fserver. Perhaps AIM7 dbase and fserver really suck.
> They seem rather impervious to other improvements in the kernel.
Yes, they do.
> > Care to share your aim7 database methodology with me?
>
> AIM7 dbase takes a mixture of AIM9 micro activities and runs
> them in proportion to what it's developers found a circa 1996
> database running.
AIM7 dbase would probably be more interesting if it created a larger working
set.
-
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/