>
> FYI, I was playing around with AIM7 on Linux-Origin last week, trying to
> diagnose why performance was so bad. I didn't get very far, yet. Even
> when I stripped the AIM7 subtests down to a single compute-bound test, I
> wasn't seeing 'top' report that process as compute-bound.
>
> A known standalone compute-bound program (i.e., a simple program that
> just loops) does get seen by 'top' and 'vmstat' as compute-bound.
> Multiple copies of that program do appear to property share the overall
> available CPU cycles.
>
> But there's something about the AIM environment that isn't behaving
> well. AIM uses forked children and pipes for parent-child
> communication. Perhaps it's something in there. Or perhaps the
> stripped-down AIM is just executing each subtest within the
> display-refresh time. I need to play with it more.
>
> When I ran the same AIM7 workload that I typically run on an SMP i386
> Kayak -- a workload that runs compute-bound -- I see pretty awful
> performance on Origin. On my i386 (two 266-MHz PentiumII) my AIM7 peaks
> at about 50 jobs/minute and stays fairly flat until 80 or 90 or so (when
> it begins to thrash). On a 2-200Mhz O200 I see a peak below *10* (at
> half the performance of the i386) and a huge falloff from there.
> Something is clearly wrong.
>
> John H.
>
John,
I comnpiled a while(1) program, and ran it on a UP kernel, watching
what top shows. Nearly 100% cpu time. 2 copies share 50% cpu time.
Running and timing 2 copies over a wall time of 20 seconds yields
user times of nearly 10 seconds for each. Experiments suggested by
Ananth.
Looking good.
Kanoj
|