Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261823AbUKPV3x (ORCPT ); Tue, 16 Nov 2004 16:29:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261821AbUKPV3x (ORCPT ); Tue, 16 Nov 2004 16:29:53 -0500 Received: from mx1.elte.hu ([157.181.1.137]:62867 "EHLO mx1.elte.hu") by vger.kernel.org with ESMTP id S261823AbUKPV3n (ORCPT ); Tue, 16 Nov 2004 16:29:43 -0500 Date: Tue, 16 Nov 2004 23:31:35 +0100 From: Ingo Molnar To: Florian Schmidt Cc: "K.R. Foley" , Mark_H_Johnson@raytheon.com, linux-kernel@vger.kernel.org, Lee Revell , Rui Nuno Capela , Bill Huey , Adam Heath , Thomas Gleixner , Michal Schmidt , Fernando Pablo Lopez-Lezcano , Karsten Wiese , Gunther Persoons , emann@mrv.com, Shane Shrybman , Amit Shah , Stefan Schweizer Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Message-ID: <20041116223135.GA27250@elte.hu> References: <20041116184315.GA5492@elte.hu> <419A5A53.6050100@cybsft.com> <20041116212401.GA16845@elte.hu> <20041116222039.662f41ac@mango.fruits.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041116222039.662f41ac@mango.fruits.de> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1826 Lines: 42 * Florian Schmidt wrote: > I have not yet tried to get this kernel to lock up yet, but i made > another interesting observation: > > irq 8 at prio 98 (only irq 1 with higher prio 99). running rtc_wakeup > in the console (it runs SCHED_FIFO allright). Switching consoles > (different text consoles - not swithcing to X, though this basically > produces similar results) produces large jitters (around 1 ms) and > occasional missed irq's and piggy messages. This is completely > reproducable here. The rtc histogram doesn't show any large wakeup > latencies. interesting, i'll try to reproduce this. btw., for best rtc_wakeup results you should chrt IRQ#0 to prio 99 too, because it uses rtc_lock, otherwise it's an extra PI pass to undo the lock inversion, which adds another 10 usecs or so to the worst-case path. and i'd suggest to chrt irq 1 back to below prio 90, maybe this explains the console-switching latency? If you do a console-switch via the keyboard then its priority 99 can get inherited by events/0 which then does the quite expensive VGA console clearing/copying with priority 99, possibly delaying rtc_wakeup quite significantly, easily for a millisecond or so. So what you are seeing might be priority inheritance handling at work! > I sometimes do get large values in /proc/latency_trace, but they seem > to be unrelated to the console switching. could you post such a large latency trace? Are they like the bad traces Mark is occasionally seeing, with some ridiculously large latency and a ridiculously short execution trace? Ingo - 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/