Daniel Rock wrote: > Thomas Maier-Komor schrieb: >> Hi, >> >> I am once again looking at a kstat output and trying to understand what >> some of these fields might mean and what their unit might be. >> Unfortunately the units aren't documented anywhere, are they? > > Use the source, Luke! >
;-) Asking and getting a good answer has sometimes the advantage that one can avoid to make the same mistake someone else already made and be much faster a the same time... >> biostats is probably the statistics for the ddi I/O buffers of Solaris >> that are accessible via bioinit(9f). So lookup and cache hits and misses >> are counted here. Unit is probably "each". > > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/bio.c#biostats > > > Later in the same file you can look up when the statistics will be > incremented. But I don't think biostats are of much interest any more. > Great pointer! BTW: your comment concerning biostats is unfortunately not included in the source - so I'm really glad that I asked, because I was considering using it ;-) > >> Concerning ufs_inode_cache and hsfs_hsnode_cache, I'd like to know what >> unit buf_inuse has. Is it kB or pages or something else? > > Unit is number of elements, as with all kstat entries of class > "kmem_cache". > > >> BTW: is the result sysconf(_SC_CPUID_MAX) the maximum id a processor can >> have or the maximum id no processor will ever have? > > Well, sysconf(_SC_CPUID_MAX) ends finally in the kernel: > > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/syscall/sysconfig.c#165 > > > max_cpuid is initialized to a default value of (NCPU - 1) - some > architectures may re-set max_cpuid: > > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/cpu.c#max_cpuid > > > So _SC_CPUID_MAX returns the maximum possible value. If a architecture > supports cpuids from 0..31 (total 32 cpus) then sysconf(_SC_CPUID_MAX) > will return 31. So you should iterate over > Thanks! I thought it must be like this, but wasn't sure. Having a reference where one can look is always good. Although the sources of Solaris are available and browsing them is interesting, this isn't really enough to know them and be sure one interprets a piece of code correctly and doesn't miss anything in another part. Concerning the board utilities the sources are great, because they mostly concern a couple of files over which you quickly get an overview and goodd understanding. But the kernel takes more time than I can spend, as I really get paid for doing something else... > for(cpuid = 0; cpuid <= cpuid_max; ++cpuid) > ... > > But for my performance gathering tool I wrote a few years ago I didn't > bother to get _SC_CPUID_MAX at all. I just iterated over all kstat > entries while searching for the right kstat modules: > > ncpu = 0; > for(ksp = kc->kc_chain; ksp != NULL; ksp = ksp->ks_next) > { > cpu_stat_t *cp; > > if((ksp->ks_type != KSTAT_TYPE_RAW) || > (strncmp(ksp->ks_module, "cpu_stat", 8))) > continue; > if(kstat_read(kc, ksp, NULL) == -1) > continue; > ++ncpu; > [...] > } > I also iterate only once and search for the modules/classes of interest. Why do you use strncmp? Are ks_module and Co not guaranteed to be null terminated or did you mix it up with ks_name which includes the trailing id? I need _SC_CPUID_MAX, because I only want to allocate memory once for all CPUs. It doesn't really matter if I ever use this memory, because the amount is so low that it is altogether at maximum two pages. OTOH this approach makes the source code a little bit smaller and faster to implement. > It really isn't that inefficient. Even on large machines with many RAM, > lots of disks and CPUs the cumulative running time was ~60 minutes over > a period of >200 days. The program fetched every 60 seconds performance > counters from disks, network, memory and cpu. Only on Solaris 2.6 > accessing the kstat system_misc module blocked for a few seconds on > machines with large memory. > Interesting experience - thanks for sharing it. I'd like to know if the behavior concerning system_misc has improved with later Solaris releases... > > Daniel > Cheers, Tom _______________________________________________ opensolaris-discuss mailing list [email protected]
