[lkml]   [2010]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 00/10] taskstats: Enhancements for precise accounting
    On Mon, 27 Sep 2010 11:18:47 +0200
    Michael Holzheu <> wrote:

    > Hello Andrew,
    > On Fri, 2010-09-24 at 11:50 -0700, Andrew Morton wrote:
    > > > > This is a big change! If this is done right then we're heading in the
    > > > > direction of deprecating the longstanding way in which userspace
    > > > > observes the state of Linux processes and we're recommending that the
    > > > > whole world migrate to taskstats. I think?
    > > >
    > > > Or it can be used as alternative. Since procfs has its drawbacks (e.g.
    > > > performance) an alternative could be helpful.
    > >
    > > And it can be harmful. More kernel code to maintain and test, more
    > > userspace code to develop, maintain, etc. Less user testing than if
    > > there was a single interface.
    > Sure, the value has to be big enough to justify the effort.
    > But as I said, with taskstats and procfs we already have two interfaces
    > for getting task information.

    That doesn't mean it was the right thing to do! For the reasons I
    outline above, it can be the wrong thing to do and strengthening one of
    the alternatives worsens the problem.

    > Currently in procfs there is information
    > than you can't find in taskstats. But also the other way round in the
    > taskstats structure there is very useful information that you can't get
    > under proc. E.g. the task delay times, IO accounting, etc.

    Sounds like a big screwup ;)

    Look at it this way: if you were going to sit down and start to design
    a new operating system from scratch, would you design the task status
    reporting system as it currently stands in Linux? Don't think so!

    > So currently
    > tools have to use both interfaces to get all information, which is not
    > optimal.
    > > >
    > > > > I worry that there's a dependency on CONFIG_NET? If so then that's a
    > > > > big problem because in N years time, 99% of the world will be using
    > > > > taskstats, but a few embedded losers will be stuck using (and having to
    > > > > support) the old tools.
    > > >
    > > > Sure, but if we could add the /proc/taskstats approach, this dependency
    > > > would not be there.
    > >
    > > So why do we need to present the same info over netlink?
    > Good point. It is not really necessary. I started development using the
    > netlink code. Therefore I first added the new command in the netlink
    > code. I also thought, it would be a good idea to provide all netlink
    > commands over the procfs interface to be consistent.

    Maybe we should have delivered taskstats over procfs from day one.

     \ /
      Last update: 2010-09-27 22:07    [W:0.044 / U:3.740 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site