Re: statistics infrastructure (in -mm tree) review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux