Keith McGuigan wrote:
Is it possible for the value returned by this to change over the
lifetime of an application? Even in a zone? The current
documentation doesn't say anything about return values being fairly
constant, though I've found some old documentation that does.
I think I've run into a situation where this returns 1, but then
later the application runs in SMP mode (in a zone with
"dedicated-cpus: ncpus 1-2"). Is this supposed to be possible?
Also, what's the difference between _SC_NPROCESSORS_CONF and
_SC_PROCESSORS_MAX?
In general, applications that care about the number of CPUs on the
machine (other than perhaps one vs many) are doing something wrong.
This sort of behavior is often seen in applications that attempt
to create the same number of threads as available CPUs in order
to optimize performance for code that uses barrier synchronization.
While perhaps tractable in a benchmarking situation, such
thread configuration presupposes exclusive access to the
resources in question over the length of the process invocation,
an unrealistic assumption in general. When the desired number
of CPUs fail to materialize (due to other tasks being run on
the box, DR, etc), performance of the barrier sections drop
dramatically as N-1 or N-2 threads spin waiting for the other
CPUs to become free, or for their own time quanta to expire.
A more performance-robust architecture is that of the
"work pile", where the units of work outnumber the max. available
concurrency by 10x or more. Missing CPUs don't matter, because
the units of work are small enough that others can fill in.
- Bart
--
Bart Smaalders Solaris Kernel Performance
ba...@cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
