Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261191AbVAGBBb (ORCPT ); Thu, 6 Jan 2005 20:01:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261153AbVAGA71 (ORCPT ); Thu, 6 Jan 2005 19:59:27 -0500 Received: from relay01.pair.com ([209.68.5.15]:52485 "HELO relay01.pair.com") by vger.kernel.org with SMTP id S261191AbVAGAs5 (ORCPT ); Thu, 6 Jan 2005 19:48:57 -0500 X-pair-Authenticated: 24.241.238.70 Message-ID: <41DDDC73.5040209@cybsft.com> Date: Thu, 06 Jan 2005 18:48:51 -0600 From: "K.R. Foley" User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark_H_Johnson@raytheon.com CC: Lee Revell , Andrew Morton , Bill Huey , Adam Heath , linux-kernel@vger.kernel.org, Ingo Molnar , Florian Schmidt , Fernando Pablo Lopez-Lezcano , Rui Nuno Capela , Steven Rostedt , Thomas Gleixner Subject: Re: Real-Time Preemption, comparison to 2.6.10-mm1 References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2848 Lines: 85 Mark_H_Johnson@raytheon.com wrote: >>Do you have a simple way of triggering and trapping the starvation? That >>of course is probably asking for a lot. :) > > > What I have been doing is now recorded as bug #3997 at > http://bugme.osdl.org/show_bug.cgi?id=3997 > Running latencytest has the advantage of generating some charts > that I can show others how well (or poorly) the system runs. > > I just rebooted in SMP and did a few other tests with the following > steps that should be simpler to set up and run. > > [1] Create cpu_test.c as follows: > > #define LOOPS 100000000 > int main() { > int u, v, k, l; > for (v=0; v<100; v++) { > for (u=0; u k += 1; > if (!(u%100)) { > l += 1; > k = 0; > } > } > } > return k; > } > > On my 866 Mhz Pentium III, it runs for about 3 minutes, 45 seconds. > Adjust the outer loop in the code if you need to run shorter or > longer. I would not run more than 5 minutes - you should easily > get the symptom before then. This also puts a limit of how long > you have to wait if the system gets "stuck" and does not respond > to your keyboard or mouse. > > [2] Build the application > gcc -o cpu_test cpu_test.c > > [3] On a two CPU system (or repeat this step N-1 times for > your N cpu system). Run in a separate window... > chrt -f 10 ./cpu_test > > [4] In a separate window... > nice ./cpu_test > > At this point, you should have the system 100% utilized with N-1 > real time applications & 1 nice application. I used top to confirm > this result. > > [5] In a separate window do one or more of the following: > a. head -c $1 /dev/zero >tmpfile > (replacing $1 with about 1.5x your physical memory size > - this is my "disk write" test) > b. cp tmpfile tmpfile2 > (this is my "disk copy" test) > c. cat tmpfile tmpfile2 >/dev/null > (this is my "disk read" test) > delete the files when done. > > It appears (at least on my system) that disk I/O triggers the > problem more than the other tests (x11perf, top [with no delay]). > > I was however in an odd situation [just before I sent this message] > where it appeared that the disk copy was OK but I could not > type on any of my windows - mouse entries were OK but not the > keyboard. That may be a different variant of my "starvation > problem". > > --Mark > > I have been able to reproduce this on my system. Actually I can pretty much put the system to sleep, at least to all external input/output, for a period of time. I haven't had time to look into this further but will try to later tonight. kr - 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/