On Fri, 24 Sep 2010 11:10:15 +0200 Michael Holzheu <holzheu@xxxxxxxxxxxxxxxxxx> wrote: > Hello Andrew, > > On Thu, 2010-09-23 at 13:11 -0700, Andrew Morton wrote: > > > GOALS OF THIS PATCH SET > > > ----------------------- > > > The intention of this patch set is to provide better support for tools like > > > top. The goal is to: > > > > > > * provide a task snapshot mechanism where we can get a consistent view of > > > all running tasks. > > > * provide a transport mechanism that does not require a lot of system calls > > > and that allows implementing low CPU overhead task monitoring. > > > * provide microsecond CPU time granularity. > > > > 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. > > > 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? 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 ;) > Are PIDs over all namespaces unique? Nope. The same pid can be present in different namespaces at the same time. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
