kirkby@t2:[~] $ /usr/sbin/psrinfo -p
2
Sun T5240
which has 128 hardware threads. Each processor T2+ has 8 cores, so 16
cores in totlal.
kirkby@t2:[~] $ /usr/sbin/psrinfo -v
Status of virtual processor 0 as of: 06/28/2009 11:02:34
on-line since 06/18/2009 04:11:30.
The sparcv9 processor operates at 1167 MHz,
and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 06/28/2009 11:02:34
on-line since 06/18/2009 04:11:32.
<SNIP over 100 virtual processors>
Status of virtual processor 126 as of: 06/28/2009 11:10:12
on-line since 06/18/2009 04:11:33.
The sparcv9 processor operates at 1167 MHz,
and has a sparcv9 floating point processor.
Status of virtual processor 127 as of: 06/28/2009 11:10:12
on-line since 06/18/2009 04:11:33.
The sparcv9 processor operates at 1167 MHz,
and has a sparcv9 floating point processor.
What sort of load average reported via prstat would be considered
reasonable, and not limited too much by available processing power? 16
seems most logical to me, but perhaps it's 128.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
> What sort of load average reported via prstat would be considered
> reasonable, and not limited too much by available processing power? 16
> seems most logical to me, but perhaps it's 128.
With CMT systems (or, really, with any system with a large number of
(virtual) CPUs) you really need more detail than the load-average. The
load average is the number of processes (threads, I guess) which "want
to run", and with 128 CPUs it looks like there could be 128 and you'd
be fine. But of course, these processes can be competing for resources
within the processor itself on a CMT system, and even on non-CMT
systems with large numbers of CPUs there are many kinds of resource
contention (for memory bandwidth, for locking etc). Worse, even a
single process which can "always run" may, in fact, be spending the
great majority of its time waiting for memory, or otherwise with the
processor stalled. CMT systems try and avoid this by having multiple
virtual threads per physical core, so when a thread is stalled (usually
waiting for memory) other threads can run.
So I guess, what I'm trying to day is "it's complicated, and the single
number we all tend to use is really a bad summary of the situation for
modern systems, especially CMT systems".
-tim
I've run a similar system with a load average of 400 and interactive
sessions were still usable. It does however depend on your workload; if
there is lots of IO the system may crap out at a much lower value.
--
Atheists are not anti-god, they are not at war with theists. They
just don't believe that gods, devils etc exist at all.
> Sun T5240
>
> which has 128 hardware threads. Each processor T2+ has 8 cores, so
> 16 cores in totlal.
[,,,[
> What sort of load average reported via prstat would be considered
> reasonable, and not limited too much by available processing power?
We have these system running in production with Apache with a stable
load of about the number of hardware threads fine (128 in this
case). More than that affects the response time and may make the
machine unstable in terms of load peaks and response time (not in
terms of crashing).
The machines with 256 hardware threads begin to get less stable
(again, in terms of load peaks and response time only) a bit
earlier, at a load of over 200 but well under 256. This may be due
to a bottleneck in the network throughput (HTTP and NFS, mostly),
according to a colleague.
--
Don't worry about the world coming to an end today. It's already
tomorrow in Australia. -- Charles Schultz
Thank you very much. So I wont fell too guilty if I push this box to a
load average of 100 doing some compiling in parallel.
It seemed quite responsive, but then I'm on the other side of the
Atlantic via a text-based ssh connection, so I don't know what
interactive performance would have been like - though I doubt they have
a mouse connected to it.
I don't really have a need, or a desire too look too deeply into this.
It's not a production machine - just a test box.
Dave