Re: statistics infrastructure (in -mm tree) review

[Martin Peschke <mp3@de.ibm.com>]

On Sat, 2006-06-17 at 08:51 +0200, Andi Kleen wrote:
> > b) Export statistic_add_counter(), statistic_add_histogram() and the like
> >     as part of the programming API (maybe in addition to the flexible
> >     statistic_add()) for those exploiters that definitively can't effort
> >     branching into a function.
> >
> >     Loss in functionality (exploiting kernel code dictates how users see
> > the data), a bit faster than option a).
> 
> (b) if anything.

Yes, I have anticipated this choice. I am looking into this option.

> But do we really need all these weird options anyways? 

Which options?

Assuming you refer to the distinction of counter, histogram, utilisation
indicator etc. ... well, that's what I found when was looking into
existing approaches: counters everywhere, histograms for example in the
s390 DASD driver, some with linear scale, other with logarithmic scale,
counters that only make sense if seen in combination (which made me come
up with this utilisation indicator thing), ...

I have just been trying to find a simple concept to reconcile various
ways of preprocessing statistics data. This is reflected by
struct statistic_discipline.

> For me it seems you're far overdesigning.
> I think your whole approach is about 10x too complicated.

I disagree.
The programing interface is simple.
The modularisation of data processing modes is straight-forward.

I have tried to break down my design into a dozen and a half
assumptions in my other mail.
I am happy to discuss which of them make sense, which of them
might be overkill, which might be deferred, etc.

But please understand that it is hard for me to guess which
10th part of my design is okay for you, if you don't go into details.

A fair share of complexity is caused by performance considerations
(per-cpu data). Which should be fine.
And, in that regard, my code isn't quite as complex yet as
lib/profile.c.

Thanks, Martin

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