svn commit: r239598 - head/etc/rc.d

[Ian Lepore]

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