Richard Lowe <richlowe at richlowe.net> 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.
I do not quite see how kstats can be used to represent trees. What do
you have in mind here?
- akolb
