On Sun, Jan 13, 2002 at 03:35:08PM -0500, Mark Hahn wrote:
> > > > 13-pre5aa1 18-pre2aa2 18-pre3 18-pre3s 18-pre3sp 18-pre3minill
> > > > j100: 6:59.79 78% 7:07.62 76% * 6:39.55 81% 6:24.79 83% *
> > > > j100: 7:03.39 77% 8:10.04 66% * 8:07.13 66% 6:21.23 83% *
> > > > j100: 6:40.40 81% 7:43.15 70% * 6:37.46 81% 6:03.68 87% *
> > > > j100: 7:45.12 70% 7:11.59 75% * 7:14.46 74% 6:06.98 87% *
> > > > j100: 6:56.71 79% 7:36.12 71% * 6:26.59 83% 6:11.30 86% *
> > > >
> > > > j75: 6:22.33 85% 6:42.50 81% 6:48.83 80% 6:01.61 89% 5:42.66 93% 7:07.56 77%
> > > > j75: 6:41.47 81% 7:19.79 74% 6:49.43 79% 5:59.82 89% 6:00.83 88% 7:17.15 74%
> > > > j75: 6:10.32 88% 6:44.98 80% 7:01.01 77% 6:02.99 88% 5:48.00 91% 6:47.48 80%
> > > > j75: 6:28.55 84% 6:44.21 80% 9:33.78 57% 6:19.83 85% 5:49.07 91% 6:34.02 83%
> > > > j75: 6:17.15 86% 6:46.58 80% 7:24.52 73% 6:23.50 84% 5:58.06 88% 7:01.39 77%
> > >
> > > Again, preempt seems to reign supreme. Where is all the information
> > > correlating preempt is inferior? To be fair, however, we should bench a
> > > mini-ll+s test.
> >
> > Your wish is granted. Here are the results for mini-ll + scheduler:
> >
> > j100: 8:26.54
> > j100: 7:50.35
> > j100: 6:49.59
> > j100: 6:39.30
> > j100: 6:39.70
> > j75: 6:01.02
> > j75: 6:12.16
> > j75: 6:04.60
> > j75: 6:24.58
> > j75: 6:28.00
>
> how about a real benchmark like -j2 or so (is this a dual machine?)
Why does everybody think this is no *real* benchmark? When I remember
the good old days at the university the systems I tried to compile some
applications on were *always* overloaded. Would it make a difference for
you if I would run
for a in lots_of.srpm; do
rpm --rebuild $a &
done
Basically this gives the same result: lots of compile jobs running in
parallel. All *I* am doing is doing it a little extreme since running
the compile with make -j2 does not make a *noticable* difference at all.
And as I said previously my idea was to get the system into high memory
pressure and test the different vms (AA and RvR) ...
Furthermore some people think this combination (sched+preempt) is only
good for latency (if at all) all I can say is that this works *very*
well for me latency wise. Since I don't know how to measure latency
exactly I tried to run my compile script (make -j50) while running my
usual desktop + xmms. Result: xmms was *not* skipping, although the
system was ~70MB into swap and the load was >50. Changing workspaces
worked immedeatly all the time. But I was able to get xmms to skip for
a short while by starting galeon, StarOffice, gimp with ~10 pictures
all at the same time. But when all applications came up xmms was not
skipping any more and the system was ~130MB into swap. This is the best
result for me so far but I have to admit that I did not test mini-ll
+sched in this area (I can test this earliest on wednesday, sorry).
Since it is a little while since I posted my system specs here they are:
- Athlon 1.2GHz (single proc)
- 256 MB
- IDE drive (quantum)
> also, I've often found the user/sys/elapsed components to all be interesting;
> how do they look? (I'd expect preempt to have more sys, for instance.)
13-pre5aa1 18-pre2aa2 18-pre3 18-pre3s 18-pre3sp 18-pre3smini
(sys) (user)
j100: 30.78 297.07 32.40 294.38 * 27.74 296.02 27.55 292.95 28.30 297.67
j100: 30.92 297.11 33.04 295.15 * 29.14 296.25 26.88 292.77 28.13 296.44
j100: 29.58 297.90 34.01 294.16 * 27.56 295.76 26.25 293.79 27.96 296.47
j100: 30.62 297.13 32.00 294.30 * 28.47 296.46 27.64 293.42 27.50 297.47
j100: 30.48 299.43 32.28 295.42 * 27.77 296.44 27.53 292.10 27.23 297.24
As expected the system and the user times are almost identical. The "fastest"
compile results are always where the job gets the most %cpu time. So I guess
it would be more interesting to see how much cpu time e.g. kswapd gets.
Probably I have to enhance my script to run vmstat in the background ...
Would this provide useful data?
Regards,
Jogi
--Well, yeah ... I suppose there's no point in getting greedy, is there?
<< Calvin & Hobbes >> - 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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:42 EST