On Fri, Apr 23, 2004 at 04:47:33PM -0700, Bill Studenmund wrote:
> On Thu, Apr 22, 2004 at 08:11:37PM -0700, Andrey Petrov wrote:
> > On Fri, Apr 23, 2004 at 07:56:41AM +0900, enami tsugutomo wrote:
> > > > , uvm_history seems closest by functionality but too tied to uvm and
> > > > somewhat too heavy for .S codes.
> > > 
> > > The latter is true but former is not.  I'm curious why do you think
> > 
> > Have to agree 'too tied' is overstatement, I looked at uvmhist _after_
> > I started using ktr so things like multiple buffers, explicit initialization,
> > strlens and UVMHIST_FUNC presets looked excessive for what I need.
> 
> I don't think it's excessive. It's great for the time when you need just a 
> little bit more than what you have now.
> 
> Multiple buffers are so that different subsystems can log or not log as 
> they see fit.

Control over subsystem logging can be done by mask, while merging different
buffers when you need to see interactions between subsystems could be
somewhat difficult.

>               UVMHIST_FUNC lets you name what routine the events come 
> from. I agree you pretty much always want the name of the routine,so 
> __FUNCTION__ would have been fine..
> 
> The strlens seemed weird for me at first. But they make sense when you 
> remember that the history's dumped by a libkvm-using program in userland. 
> By having explicit lengths, extracting data from the kernel is much more 
> efficient.
> 

Seems that priority is reversed here, it's more important to be efficient
when data is being collected, then when it's dumped.

Overall I see some advantages in bsdi's version, plus there is a need
to rework uvmhist to make it generic. I'd propose to import kern_ktr
now and I'd switch uvmhist to use it later. If there are objections
to this approach please speak up.

Thanks for responses,
	Andrey