From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261969AbULKRCs (ORCPT ); Sat, 11 Dec 2004 12:02:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261970AbULKRCs (ORCPT ); Sat, 11 Dec 2004 12:02:48 -0500 Received: from mail.timesys.com ([65.117.135.102]:25783 "EHLO exchange.timesys.com") by vger.kernel.org with ESMTP id S261969AbULKRCk (ORCPT ); Sat, 11 Dec 2004 12:02:40 -0500 Message-ID: <41BB2785.7020006@timesys.com> Date: Sat, 11 Dec 2004 11:59:49 -0500 From: john cooper User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Rostedt CC: Mark Johnson , 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 , john cooper Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 References: <1102722147.3300.7.camel@localhost.localdomain> In-Reply-To: <1102722147.3300.7.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2004 16:55:04.0937 (UTC) FILETIME=[29A19D90:01C4DFA2] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt wrote: > [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. I think there are two issues here. One being as above which addresses allowing the server thread to compete for CPU time at a priority equal to its highest waiting client. Essentially the server needs no inherent priority of its own, rather its priority is automatically inherited. The semantics seem straightforward even in the general case of servers themselves becoming clients of other servers. Another issue is the fact the server thread is effectively non-preemptive. Otherwise a newly arrived waiter of priority higher than a client currently being serviced would receive immediate attention. One problem to be solved here is how to save/restore client context when a "context switch" is required. -john -- john.cooper@timesys.com