Re: statistics infrastructure (in -mm tree) review

[Matthew Frost]

Martin Peschke wrote:
> On Tue, 2006-06-20 at 09:50 -0700, Randy.Dunlap wrote:
> > On Tue, 20 Jun 2006 17:40:01 +0200 Martin Peschke wrote:
> > > Greg KH wrote:
> > > > > 7) With regard to the delivery of statistic data to user land,
> > > > > a library maintaining statistic counters, histograms or whatever
> > > > > on behalf of exploiters doesn't need any help from the exploiter.
> > > > > We can avoid the usual callbacks and code bloat in exploiters
> > > > > this way.
> > > > I don't really understand what you are stating here.
> > > Sorry.
> > > 1,$s/exploiter/client/g
> > >
> > > Any device driver or whatever gathering statistics data currently
> > > has code dealing with showing the data. Usually, they have some
> > > callbacks for procfs, sysfs or whatever.
> > >
> > > My point is that, if a library keeps track of statistics on behalf
> > > of its clients, no client needs to be called back in order to
> > > merge, format, copy, etc. data being shown to users. The library
> > > can handle as a background operation without disturbing clients.
> > That could be a good thing.  OTOH, it means that the library
> > has to be either all-ways flexible or willing to change to
> > accommodate clients since you can't predict the universe of all
> > clients' requirements.
>
> Right. I have made provisions for that to some degree.
>
>
> First, I could imagine that the statistics data of a client requires
> a new way its data should be aggregated and, therewith, requires
> a new form of statistic result being shown to users.
>
> I have scanned through the kernel sources for ways of aggregating
> and showing statistics data. The usual constructs appear to be:
>
> - counter
> - histogram (for intervals), linear scale
> - histogram (for intervals), logarithmic scale
> - "histogram" for discrete and sparse values
> - "utilisation indicator" or "fill level indicator" (num-min-avg-max)
>
> These are implemented in my patches. I would expect these to cover most
> requirements of possible new clients.

So you're saying, as regards "putting presentation format in ... the 
kernel", that we already have presentation formats specified pell-mell 
in the kernel.  That should then be a non-issue, because you aren't 
introducing anything new, just centralizing an existing kernel behavior. 
 Do I have you right?

> If another construct would be needed anyway, it can be added to the
> statistics library by implemententing about half a dozen routines
> described by struct statistic_discipline. I might be wrong, but I don't
> think we would see an inflationary growth there.
-- elision --
> OTOH, I don't see a real need for allowing that. Data can be reformatted
> and rearranged in any possible way in user space.

Because you're just providing a range of basic output formats, 
standardized.  So anybody can ask for statistics from the kernel in a 
preferred output to then massage as needed in userland.  ACK?  Am I 
oversimplifying?

Matt


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/