From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761047AbZE1PFQ (ORCPT ); Thu, 28 May 2009 11:05:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757068AbZE1PFD (ORCPT ); Thu, 28 May 2009 11:05:03 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]:59630 "EHLO mtagate8.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbZE1PFB (ORCPT ); Thu, 28 May 2009 11:05:01 -0400 Message-Id: <20090528150447.152019714@de.ibm.com> User-Agent: quilt/0.46-1 Date: Thu, 28 May 2009 17:04:47 +0200 From: Martin Schwidefsky To: linux-kernel@vger.kernel.org Cc: Rob van der Heij , Heiko Carstens , Ingo Molnar , Thomas Gleixner , john stultz Subject: [patch 0/2] NOHZ vs. profile/oprofile Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greetings, Rob pointed me to a deficiency with the current profile/oprofile code together with NOHZ. For us this problem crept in with the conversion of s390 to generic clock events, git commit 5a62b192 If the system is running with the HZ-tick disabled and the cpu spents time in idle we see skewed percentages e.g. with the oprofile output. On an I/O bound system the number of idle ticks is way to small. The reason is that the generic clock events code reports either zero or one tick to profile/oprofile on wakeup from idle even if the cpu has slept much longer. I've tried to fix that with the two patches in this series and another pure s390 specific fix (profile_tick is called from clock_comparator_work which is nonsense). These three do correct the oprofile output on s390. The best idea I had to get oprofile in good shape again is to let the system tick at the HZ rate while oprofile is working. Better ideas welcome. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.