Alexander Kolbasov <[EMAIL PROTECTED]> writes: > Richard Lowe <[EMAIL PROTECTED]> wrote: > > >> Currently some CPU-related information can be obtained using > >> prtconf(1M) and psrinfo(1M) which just a wrapper around the kstat (1M) > >> framework. The kstat framework is usable for representing simple > >> "flat" CPU properties, but using it becomes more and more of a stretch > >> in the CMT world. > >> > >> The purpose of the CPUfs project is to explore using the file system > >> abstraction to represent CPU properties. File system abstraction > >> supports hierarchy and convenient name space. > >> > >> I suggest hosting the project under either Observability or > >> Performance community. > >> > > RL> While I agree that greater observability here is desirable, it'd be > RL> good to see some rational as to why kstat can't provide it, and, > RL> beyond that, why a pseudo-fs is the better choice. > > RL> lgrps form a nice, pleasant, tree. PGs seem to bring a more complex > RL> hierarchy, given the number of possible relationships they represent, > RL> but I'm not immediately seeing how a pseudo-fs makes that more > RL> pleasant than kstat (given the filesystem would, I suppose, be > RL> presenting it as that same "nice, pleasant, tree", almost by > RL> definition). > > Lgroups map very nicely to the filesystem representation. PGs represent > a tree as well. CMT relationships can be represented using <belongs to> > relationship which can be expressed as a tree. For example, we can put > more generic components at the top of the tree and put sub-components as > trees with CPUs as leaf nodes. We can also use symlinks for cross-brunch > links. All of this maps naturally to the filesystem. I'd like to be able > to use plain shell constructs to extract at least most useful > information from the tree.
Ah, it was using a web of symlinks to cross branches that I was missing. > I do not quite see how kstats can be used to represent trees. What do > you have in mind here? I think what I had in mind falls apart for PGs. My expectation was that the basic method used now to represented core/chip relationships could be expanded upon, but I don't think that holds up to even moderately complex topologies. -- Rich _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
