From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [RFC][PATCH 00/10] taskstats: Enhancements for precise accounting Date: Fri, 24 Sep 2010 11:50:02 -0700 Message-ID: <20100924115002.fcb4385a.akpm@linux-foundation.org> References: <1285249681.1837.28.camel@holzheu-laptop> <20100923131136.356075f4.akpm@linux-foundation.org> <1285319415.2179.116.camel@holzheu-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1285319415.2179.116.camel@holzheu-laptop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: holzheu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org Cc: Shailabh Nagar , Thomas-FOgKQjlUJ6BQetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Zijlstra , Heiko Carstens , Venkatesh Pallipadi , John stultz , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbir Singh , Nesterov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Oleg-FOgKQjlUJ6BQetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Martin Schwidefsky , Ingo Molnar , Peter-FOgKQjlUJ6BQetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Gleixner , Suresh Siddha List-Id: containers.vger.kernel.org On Fri, 24 Sep 2010 11:10:15 +0200 Michael Holzheu 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 24 Sep 2010 11:50:02 -0700 From: Andrew Morton Subject: Re: [RFC][PATCH 00/10] taskstats: Enhancements for precise accounting Message-Id: <20100924115002.fcb4385a.akpm@linux-foundation.org> In-Reply-To: <1285319415.2179.116.camel@holzheu-laptop> References: <1285249681.1837.28.camel@holzheu-laptop> <20100923131136.356075f4.akpm@linux-foundation.org> <1285319415.2179.116.camel@holzheu-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-Archive: List-Post: To: holzheu@linux.vnet.ibm.com Cc: Shailabh Nagar , Venkatesh Pallipadi , Suresh Siddha , Peter Zijlstra , Ingo Molnar , Oleg Nesterov , John stultz , Thomas Gleixner , Balbir Singh , Martin Schwidefsky , Heiko Carstens , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, containers@lists.linux-foundation.org List-ID: On Fri, 24 Sep 2010 11:10:15 +0200 Michael Holzheu 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.