On 2009-03-22 at 17:03:58 [+0100], Rene Gollent <anevilyak@...> wrote:
> 2009/3/21 André Braga <meianoite@...>:
> > There are such plans, indeed, as I mentioned, but I wouldn't mind if
> > someone else implemented the topology API. My usage for such API would
> > be to build a graph of migration penalties, such that cores connected
> > by slower means would receive a higher penalty (SMT* < shared cache <
> > SMT** < shared socket < shared... backplane? [and Haiku goes NUMA!])
>
> You could probably build the graph yourself if given the appropriate
> information. For example, if we extend the cpu_ent structure to
> indicate the physical id, logical id, smt id for lack of better names
> (i.e. two cores on the same physical die would share the same physical
> ID, and hyperthread/SMT would share the same phy + logical). This
> would let you walk through gCPU and build an appropriate graph, though
> this wouldn't really cover more advanced NUMA situations for the time
> being. IMO that's not likely to be an issue any time soon though, so
> we can tackle that bridge when we get to it. This solution wouldn't
> really require a great deal of time, and no new API calls would be
> necessary. Thoughts, anyone?
I'd prefer <cpu.h> to already offer a tree representation. I would introduce
a cpu_scope structure (or class) representing a tree node. The leaf nodes
would refer to the cpu_ents (respectively with C++ the cpu_ents (CPU) would
derive from cpu_scope (CPUScope)). Each node would describe the properties of
the corresponding hardware, e.g. what kind of hardware it refers to (CPU,
core, hardware thread,...) and what resources are shared by its children
(units, caches, busses, whatever).
CU, Ingo
|