Balbir Singh <[email protected]> wrote:
>
> On Wed, Mar 29, 2006 at 09:03:14PM -0800, Andrew Morton wrote:
> > Shailabh Nagar <[email protected]> wrote:
> > >
> > > Could you please include the following delay accounting patches
> > > in -mm ?
> >
> > I'm at a loss to evaluate the suitability of this work, really. I always
> > am when accounting patches come along.
> >
> > There are various people and various groups working on various different
> > things and there appears to be no coordination and little commonality of
> > aims. I worry that picking one submission basically at random will provide
> > nothing which the other groups can work on to build up their feature.
> >
> > On the other hand, we don't want to do nothing until some uber-grand
> > all-singing, all-dancing statistics-gathering infrastructure comes along.
> >
> > So I'm a bit stuck. What I would like to see happen is that there be some
> > coordination between the various stakeholders, and some vague plan which
> > they're all happy with as a basis for the eventual grand solution.
> >
> > We already have various bits and pieces of statistics gathering in the
> > kernel and it's already a bit ad-hoc. Adding more one-requirement-specific
> > accounting code won't improve that situation.
> >
> > But then, I said all this a year or two ago and nothing much has happened
> > since then. It's not your fault, but it's a problem.
> >
> > Perhaps a good starting point would be a one-page bullet-point-form
> > wishlist of all the accounting which people want to get out of the kernel,
> > and a description of what the kernel<->user interface should look like.
> > Right now, I don't think we even have a picture of that.
> >
> > We need a statistics maintainer, too, to pull together the plan,
> > coordinate, push things forwards. The first step would be to identify the
> > stakeholders, come up with that page of bullet-points.
> >
> > Then again, maybe the right thing to do is to keep adding low-impact
> > requirement-specific statistics patches as they come along. But if we're
> > going to do it that way, we need an up-front reason for doing so, and I
> > don't know what that would be.
> >
> > See my problem?
>
> One of the issues we have tried to address is the ability to provide some
> form of a common ground for all the statistics to co-exist. Various methods
> were discussed for exchanging data between kernel and user space, genetlink
> was suggested often and the clear winner.
>
> To that end, we have created a taskstats.c file. Any subsystem wanting
> to add their statistics and sending it to user space can add their own
> types by extending taskstats.c (changing the version number) and creating
> their own types using genetlink. They will have to do the following
>
> 1. Add statistics gathering in their own subsystem
> 2. Add a type to taskstats.c, extend it and use data from (1) and send
> it to user space.
>
> The data from various subsystems can co-exist. I feel that this could serve as
> the basic common infrastructure to begin with and refined later (depending on
> the needs of other people).
>
Sounds fine to me, but I'm not a stakeholder.
Trolling back through lse-tech gives us:
pnotify:
Erik Jacobson <[email protected]>
CSA accounting/PAGG/JOB:
Jay Lan <[email protected]>
Limin Gu <[email protected]>
per-process IO statistics:
Levent Serinol <[email protected]>
ELSA:
Guillaume Thouvenin <[email protected]>
per-cpu time statistics:
Erich Focht <[email protected]>
Scalable statistics counters with /proc reporting:
Ravikiran G Thirumalai <[email protected]>
(Kiran feft IBM, but presumably the requirement lives on)
There was a long thread "A common layer for Accounting packages". Did it
come to a conclusion?
Anyway, if mostly everyone is mostly happy with what you propose then that
it good news.
-
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]
