From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261875AbULJXnH (ORCPT ); Fri, 10 Dec 2004 18:43:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261879AbULJXnH (ORCPT ); Fri, 10 Dec 2004 18:43:07 -0500 Received: from bgm-24-94-57-164.stny.rr.com ([24.94.57.164]:29575 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id S261875AbULJXm6 (ORCPT ); Fri, 10 Dec 2004 18:42:58 -0500 Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 From: Steven Rostedt To: Mark Johnson Cc: Ingo Molnar , Amit Shah , Karsten Wiese , Bill Huey , Adam Heath , emann@mrv.com, Gunther Persoons , "K.R. Foley" , LKML , Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Shane Shrybman , Esben Nielsen , Thomas Gleixner , Michal Schmidt In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Kihon Technologies Date: Fri, 10 Dec 2004 18:42:27 -0500 Message-Id: <1102722147.3300.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2004-12-09 at 12:10 -0600, Mark_H_Johnson@raytheon.com wrote: > >but you never want your real application be delayed by things like IDE > >processing or networking workloads, correct? > For the most part, that I/O workload IS because I have the RT application > running. That was one of my points. I cannot reliably starve any of > those activities. The disk reads in my real application simulate a disk > read from a real world device. That data is needed for RT processing > in the simulated system. Some of the network traffic is also RT since > we generate a data stream that is interpreted in real time by other > systems. [RFC] Has there been previously any thought of adding priority inheriting wait queues. With the IRQs that run as threads, have hooks in the code that allows a driver or socket layer to attach a thread to a wait queue, and when a RT priority task waits on the queue, a function is call to increase (if needed) the priority of the attached thread. I know that this would take some work, and would make the normal kernel and RT diverge more, but it would really help to solve the problem of a high priority process waiting for an interrupt that can be starved by other high priority processes. Just a thought. -- Steve