In the last episode (Oct 20), David Wolfskill said:
> Almost 2 years ago, we migrated from a lightly-patched 6.2-R to 7.1-R with
> 5 commits that were made to 7.1-S backported to it. On the same hardware
> (not the HP mentioned above), I measured a 35% reduction in elapsed time
> for one particular form of the build in question. This was encouraging.
>
> A couple of days ago, I updated the active slice on my 8.x reference
> machine to 8.1-STABLE #5 r214029 and proceeded to start some timed builds;
> here are some fairly raw timing data:
>
> Start Stop real user sys OS
> 1287436357 1287461948 25590.99 81502.22 18115.07 8.1-S
> 1287462797 1287488766 25969.26 81452.14 17920.14 8.1-S
> 1287489641 1287515287 25645.84 81548.40 18256.52 8.1-S
> 1287516151 1287541481 25329.64 81546.23 18294.10 8.1-S
> 1287542355 1287568599 26244.59 81431.47 17902.39 8.1-S
>
> 1287525363 1287546846 21483.13 82628.20 21703.09 7.1-R+
> 1287548005 1287569100 21094.63 82853.19 22185.02 7.1-R+
> 1287570300 1287591371 21071.33 82756.81 21943.22 7.1-R+
An observation: on 8.1, both user and sys times are less, but real time is
higher. So 8.1 finished the build using less CPU, but spent more time
waiting for something else. Disk? Network? I don't suppose the machines
are low enough on RAM that you end up swapping at any point? Maybe there
was a change to /usr/bin/make that is causing it to launch jobs slower?
Julian's suggestion of booting the 8.1 kernel on the 7.1 OS will definitely
narrow down the list of suspects.
--
Dan Nelson
dnel...@allantgroup.com
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
