I'll see you on the list (;-)) Back when I was full-time (I'm a contractor who does capacity planning), I was part of the ABI team, who managed the stable/unstable interfaces, so as not to suffer "dll hell" like some other folks we all know.
To oversimplify, "private" interfaces which change from release to release have to be tracked by outside software vendors, and they really *really* don't like doing that. Imagine being Oracle and having to check that all your uses of SUNWprivate interfaces still worked whenever you got a new OS release. There are a few companies who do so, and Oracle is (or at least was) one of them, but everyone else wants stuff to remain unchanged. In the case of a mib, which can't check a library to see if something is private or not, we'll have to set ground-rules so that one can introduce new interface names, drop old ones and never ever change the meaning of a datum without creating a new interface name for it. Not a small task! --dave Jason King wrote: > On Fri, Feb 13, 2009 at 12:09 PM, David Collier-Brown <dav...@sun.com> wrote: >> Brendan Gregg wrote: >>> No. Stop. Do not assume any data is better than no data. Wrong >>> or misleading data is *worse* than no data. >> I agree most emphatically. Most metrics recorded by programs >> are those needed by the authors of the programs. All too >> few are the ones we need to *use* the program. >> >> Solaris is good at collecting, for example, queue occupancy >> and depth instead of just depth, but we can do more. And >> the fishwork guys are the ones are doing it, for storage. >> >> I therefor suggest we *do* do more, Brendan's alternative B: >>> make an effort to export useful performance metrics, to meet >>> stated needs. Examine what's there and keep what is good (I think >>> "iostat -xne" output is great), drop what's bad (some of vmstat), >>> and add what is missing - which means adding kstats to the kernel. >> --dave (an evil contractor and capacity planner in Toronto) c-b > > I'm all for defining better metrics. Please join in the discussions > on perfmib-dev at opensolaris.org and add what things you think are > useful. The choice of the *stat commands (really more certain bits of > data that correspond to that seen by the mpstat & fsstat commands is > all that has been discussused) is that at least some of the data they > present has proven useful, and the metrics they're collecting are > unlikely to go away anytime soon, thus any arguments that the cross > call rate for a cpu metric is unstable and might go away tomorrow > (thus shouldn't ever be used by anything) are a bit harder to argue. > > The problem is that there seems to be this mortal fear that after > going through all the effort to create these nice means of obtaining > the data from the OS (kstat, dtrace, etc.) that that someone (who > isn't a Sun employee) will somewhere, somehow actually use them. > Anytime anyone suggests trying to use the data in someway that might > prove useful, they are told 'that data is not stable, you cannot use > it'. The only 'blessed (by Sun)' means of obtaining data from the > system are the *stat commands, so those are in effect the only things > we can arguably work with without getting shot down by stability > arguments, but then there's another group that says 'but those metrics > are bad! don't use those!' > > If one listens to both groups, we are left with doing nothing and > hoping that at some point in the future Sun decides to do something. > The existing commands are apparently inadequate, and Sun will shoot > down any attempt to make anything better (if they're not the ones > doing it) because the sources of the data are not deemed stable (in an > interface sense). > -- David Collier-Brown | Always do right. This will gratify Sun Microsystems, Toronto | some people and astonish the rest dav...@sun.com | -- Mark Twain cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191# _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
