Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261910AbUKJOzX (ORCPT ); Wed, 10 Nov 2004 09:55:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261843AbUKJOy0 (ORCPT ); Wed, 10 Nov 2004 09:54:26 -0500 Received: from dfw-gate1.raytheon.com ([199.46.199.230]:55590 "EHLO dfw-gate1.raytheon.com") by vger.kernel.org with ESMTP id S261910AbUKJOxH (ORCPT ); Wed, 10 Nov 2004 09:53:07 -0500 Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 To: Ingo Molnar Cc: Amit Shah , Karsten Wiese , Bill Huey , Adam Heath , emann@mrv.com, Gunther Persoons , "K.R. Foley" , linux-kernel@vger.kernel.org, Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Shane Shrybman , Thomas Gleixner , Michal Schmidt X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Mark_H_Johnson@raytheon.com Date: Wed, 10 Nov 2004 08:51:53 -0600 X-MIMETrack: Serialize by Router on RTSHOU-DS01/RTS/Raytheon/US(Release 6.5.2|June 01, 2004) at 11/10/2004 08:51:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SPAM: 0.00 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1926 Lines: 43 >* Mark_H_Johnson@raytheon.com wrote: > >> >- everything else should be SCHED_OTHER. Do latencies get any better if >> >you do this? > >> I can, but that is not necessarily an "apples to apples" comparison. > >the goal now would be to simplify the test and work down the issues in >isolation, instead of looking at a complex setup of mixed workloads and >just seeing 'it sucks' without knowing which component causes what. However based on the results of the last several weeks, it is apparent to me that the simple tests are finding only a subset of the problems. The stressful series of tests is finding a number of symptoms much sooner and more repeatable than those simple tests. I was thinking about this problem this morning and was wondering if we could do something like an "end trigger" to help determine the cause of some of these pauses. Something like: - start to fill / refresh the trace buffer (already doing this?) - run RT CPU loop & sample TSC every 100 iterations or so - if delta T exceeds 100 usec (or so), then set "end trigger" and dump the data from /proc/latency_trace. Repeat with some rate limit so we don't get too much data. I can still run the stressful test cases to cause the situations and get the "just in time" data for the analysis. Perhaps a variant of the interface you provided before on tracing a specific path. I may do a variant on this anyway. I think its important to see if the symptom (> 100 usec CPU delay) is really: - lots of short delays OR - relatively few long delays and I have an idea of how to code that up and add to latencytrace. --Mark H Johnson - 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/