On Thu, 2012-09-06 at 11:21 -0700, David O'Brien wrote: > On Thu, Sep 06, 2012 at 09:39:24AM -0600, Ian Lepore wrote: > > On Wed, 2012-09-05 at 13:40 -0700, David O'Brien wrote: > > > Of those oids you listed above, the vm and vfs generate a lot of text > > but it's mostly the vm.stats part that changes. The kern.geom output is > > pretty static on a given system, and oddly it takes a long time to > > generate compared to other oids. The cp_time is already included in > > cp_times. The dev.cpu is intel-specific. > > I'm not seeing that 'cp_time's specific values are in 'cp_times'. > I have not looked at how easy it is to derive 'cp_time' given > 'cp_times' output.
Hmmm, it must be a single vs. multiprocessor thing. From an embedded system: guava# sysctl kern.cp_time kern.cp_times kern.cp_time: 1814 34 4646 104 1449203 kern.cp_times: 1814 34 4646 104 1449203 But on my desktop machine I see what you report: a pretty large difference between the two. > At this point I am liking: > sysctl kern.cp_times kern.cp_time kern.lastpid kern.timecounter \ > kern.tty_nout kern.tty_nin vm vfs debug dev.cpu \ > | tr -Cd '0123456789xabcdef' The times for this command sequence (output of tr redirected to /dev/null) cluster right around .55s, not too bad. It generates about 2700 bytes on one of my embedded systems. -- Ian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
