[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
    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. 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. So currently
    tools have to use both interfaces to get all information, which is not

    > >
    > > > 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.

    > If the info is available via procfs then userspace code should use that
    > and not netlink, because that userspace code would also be applicable
    > to CONFIG_NET=n systems.
    > >
    > > > Does this have the potential to save us from the CONFIG_NET=n problem?
    > >
    > > Yes
    > Let's say that when it's all tested ;)

    That was more a theoretical statement :-)

    I probably still have to ensure that the kernel config options
    dependencies are done correctly.


     \ /
      Last update: 2010-09-27 20:11    [W:0.032 / U:47.356 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site