Re: statistics infrastructure (in -mm tree) review

[Matthew Frost <artusemrys@sbcglobal.net>]

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