From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754162AbYIWQaw (ORCPT ); Tue, 23 Sep 2008 12:30:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752139AbYIWQao (ORCPT ); Tue, 23 Sep 2008 12:30:44 -0400 Received: from fhw-relay07.plus.net ([212.159.14.148]:54786 "EHLO fhw-relay07.plus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751773AbYIWQan (ORCPT ); Tue, 23 Sep 2008 12:30:43 -0400 Message-ID: <48D919A9.5000708@yahoo.com> Date: Tue, 23 Sep 2008 17:30:33 +0100 From: Sitsofe Wheeler User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ingo Molnar CC: Peter Zijlstra , Arjan van de Ven , linux-kernel@vger.kernel.org, Steven Rostedt Subject: Re: How how latent should non-preemptive scheduling be? References: <48D39312.9000400@yahoo.com> <20080922115749.GE14301@elte.hu> <48D88DB4.9020003@yahoo.com> <20080923115323.GA27240@elte.hu> In-Reply-To: <20080923115323.GA27240@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Plusnet-Relay: ae70f55b2cb48d018d0e8bd3b12474d2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar wrote: > * Sitsofe Wheeler wrote: > >> Ingo Molnar wrote: >>> well, since they went away after you enabled CONFIG_PREEMPT=y, they are >>> definitely in-kernel latencies, not any external SMM latencies. >>> >>> I.e. they are inherently fixable. Could you enable: >>> >>> CONFIG_DYNAMIC_FTRACE=y >>> CONFIG_FTRACE_MCOUNT_RECORD=y >>> >>> that should make the traces a lot more verbose - every kernel function >>> executed in the latency path will be logged. That way we'll be able to >>> say which one takes that long. >> I do not appear to have the CONFIG_FTRACE_MCOUNT_RECORD option in >> 2.6.27rc7. Is it an option that is only in -tip ? > > yeah - it's a new ftrace feature queued up for v2.6.28. I've been struggling to boot -tip/master - currently it blows up just after printing SLUB information saying: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [] account_system_time+0x48/0x120 *pde = 00000000 Thread overran stack, or stack corrupted Oops: 0002 [#1] PREEMPT -- Sitsofe | http://sucs.org/~sits/