> Yes, known problem... my question is more about the problem what happens
> when there are many free CPUs/boards with "equal" priority. Is there
> anything which looks at other attributes than the hardware to shepherd
> the threads/processes to stay together or migrate in groups ?
Application's responsibility ;-)
Best regards,
Michael
Roland Mainz schrieb:
Eric Saxe wrote:
Roland Mainz wrote:
Is there any special handling of process groups to make sure that
processes (and their LWPs) are kept together ?
Think about an (imaginary (and simplified)) machine with 4 strands per
core, 4 cores per socket, 4 sockets per board and 4 boards per cabinet
and 4 cabinets where each layer increases the latency factor by 2 - in
this case it would be desireable to keep processes which often
communicate with each other closely together.
Which "factors" does Solaris consider - "process group", "uid", "process
hieracy", plain statistics or something else ?
On some platforms, Solaris will try to home threads from the same
process to the same lgroup (which
physically would be a board, node, etc). The platform specific code
plays a role in tuning the extent
to which this happens (how aggressive that coalescing policy is). It
boils down to optimizing for latency
vs. aggregate bandwidth.
You can use liblgrp(3LIB) , or plgrp(1) to implement these types of
policies yourself on any NUMA platform.
Beyond NUMA, we've been thinking about similar policy at the CMT level
as well (shared caches, etc).
Optimizing at this level can be a challenge as things tend to be quite a
bit more dynamic. ;P
Yes, known problem... my question is more about the problem what happens
when there are many free CPUs/boards with "equal" priority. Is there
anything which looks at other attributes than the hardware to shepherd
the threads/processes to stay together or migrate in groups ?
----
Bye,
Roland
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
