On Wed, Sep 19, 2001 at 02:51:11AM -0700, Brian Pane wrote:
> I think it's reasonable to assume that Solaris will make smart decisions
> about LWP locality. If you want to validate this assumption empirically,
> though, I think it's possible to get a snapshot of what CPU is running
> each LWP, via Solaris-specific ioctls on the corresponding /proc file.
> (I know this was possible in 5.6; it's probably still supported in 5.8.)
Yeah, I was purposely not playing with any CPU monitoring tools while
it was running as I didn't want to disturb the results. I may run the
tests again tonight (or this weekend if I can't get to it tonight -
I'm moving tomorrow) and watch it with the /usr/proc/bin/p* files - I
won't be paying attention to the rps this time, but the CPU performance.
> This issue, by the way, makes me favor letting the OS figure out the
> thread concurrency for itself: assuming that the number of child processes
> is greater than or equal to the number of CPUs, it might be more effective
> to have a small number of LWPs per process, with a large number of threads
> per LWP for cache locality purposes.
++1. =-)
> >- Justin mentioned that he observed much higher load on the worker tests
> > compared to the prefork tests. Something on the order of ~8 for the
> > worker case, and ~3-4 for prefork was discussed. Can someone explain
> > to us why this might be happening? It obviously didn't impact
> > performance negatively, since the worker performed slightly better.
> >
>
> I'm surprised about this result. In Ian's tests comparing worker and
> prefork on an 8-CPU Solaris box, the load average was about the same
> for both MPMs. Justin, do you remember how the usr+sys CPU utilization
> for worker compared to that of prefork in your test?
Actually, I think the CPU utilization was less with worker, but the
load was much higher. I have no clue how that is. When I run it
again, I'll keep an eye out for these values. -- justin
