Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758080Ab0KOSKp (ORCPT ); Mon, 15 Nov 2010 13:10:45 -0500 Received: from canuck.infradead.org ([134.117.69.58]:48055 "EHLO canuck.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756654Ab0KOSKo convert rfc822-to-8bit (ORCPT ); Mon, 15 Nov 2010 13:10:44 -0500 Subject: Re: [RFC][PATCH v2 4/7] taskstats: Add per task steal time accounting From: Peter Zijlstra To: Martin Schwidefsky Cc: Michael Holzheu , Shailabh Nagar , Andrew Morton , Venkatesh Pallipadi , Suresh Siddha , Ingo Molnar , Oleg Nesterov , John stultz , Thomas Gleixner , Balbir Singh , Heiko Carstens , Roland McGrath , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, "jeremy.fitzhardinge" In-Reply-To: <20101115185923.1c353d07@mschwide.boeblingen.de.ibm.com> References: <20101111170352.732381138@linux.vnet.ibm.com> <20101111170815.024542355@linux.vnet.ibm.com> <1289677083.2109.167.camel@laptop> <20101115155057.15f3be35@mschwide.boeblingen.de.ibm.com> <1289833883.2109.494.camel@laptop> <20101115184206.4463fd05@mschwide.boeblingen.de.ibm.com> <1289843441.2109.520.camel@laptop> <20101115185923.1c353d07@mschwide.boeblingen.de.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Mon, 15 Nov 2010 19:08:44 +0100 Message-ID: <1289844524.2109.524.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1208 Lines: 21 On Mon, 2010-11-15 at 18:59 +0100, Martin Schwidefsky wrote: > Steal time per task is at least good for performance problem analysis. > Sometimes knowing what is not the cause of a performance problem can help you > tremendously. If a task is slow and has no steal time, well then the hypervisor > is likely not the culprit. On the other hand if you do see lots of steal time > for a task while the rest of the system doesn't cause any steal time can tell > you something as well. That task might hit a specific function which causes > hypervisor overhead. The usefulness depends on the situation, it is another > data point which may or may not help you. If performance analysis is the only reason, why not add a tracepoint on vcpu enter that reports the duration the vcpu was out for and use perf to gather said data? It can tell you what process was running and what instruction it was at when the vcpu went away. No need to add 40 bytes per task for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/