4) ktr has a ddb log dumper. Given how similar everything is, shouldn't be 
   hard to add the same thing for uvmhist. Basically the ddb support you 
   added just given a uvmhist and taught to print them would do it.

you mean the ddb callable functions uvmhist_dump_histories(),
uvmhist_dump(), uvm_hist(), etc?
   
   6) locking. uvmhist uses splhigh() + spinlocking, while ktr uses 
   atomic_cmpset_rel_int(). As I understand that, it's a form of RAS. In the 
   long run, that'd be cool to do. But most of the NetBSD kernel just uses 
   spl for now.
   
   If you do check ktr in, you MUST address this point. I think the 
   spinlocking from uvmhist is the way to go.

yes - most platforms don't have these atomic ops implemented.
   
   7) uvmhist has separate loggers and ktr uses a mask of well-known 
   log types.

note that we currently have a mapping between a 32 bit bitmask (XXX)
and each of the uvm histories.
   
   > Would be interesting to see how libkvm-based utility does the job.
   > vmstat seems to do only a snapshot.
   
   Hmm, yeah. But all we need to do is sleep & wake up ever now & then. If we 
   assume we won't overflow the log too fast (like in a second), then this 
   should work.

i wonder if the KTRACE style of writing entries directly to disk
would work...  not necessarily for *each* one (though this would
be a nice option) but have it sync after every N...

all these need to be options IMO.  and what enami said.  :-)