lkml.org 
[lkml]   [2010]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 00/10] taskstats: Enhancements for precise accounting
On Mon, 27 Sep 2010 11:18:47 +0200
Michael Holzheu <holzheu@linux.vnet.ibm.com> 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    [from the cache]
©2003-2011 Jasper Spaans