From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261541AbULLEg6 (ORCPT ); Sat, 11 Dec 2004 23:36:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261573AbULLEg6 (ORCPT ); Sat, 11 Dec 2004 23:36:58 -0500 Received: from bgm-24-94-57-164.stny.rr.com ([24.94.57.164]:23740 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id S261541AbULLEgy (ORCPT ); Sat, 11 Dec 2004 23:36:54 -0500 Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 From: Steven Rostedt To: john cooper 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 In-Reply-To: <41BB2785.7020006@timesys.com> References: <1102722147.3300.7.camel@localhost.localdomain> <41BB2785.7020006@timesys.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Kihon Technologies Date: Sat, 11 Dec 2004 23:36:31 -0500 Message-Id: <1102826191.3691.44.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 Sat, 2004-12-11 at 11:59 -0500, john cooper wrote: > 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. > I agree with you on this. > 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. I don't quite understand your point here. Say you have process A at prio 20 that waits on a queue with server S. S becomes prio 20 and starts to run. Then it is preempted by process B at prio 30 which then comes to wait on the server's queue. Server S becomes prio 30 and finishes process A's work, then checks the queue again and finds process B and starts working on process B's work still at prio 30. The time of process B is still bounded (predictable). So it's similar to a mutex and priority inheritance. We can look at process A taking lock L and then when process B blocks on lock L, process A inherits process B's priority (B being greater prio than A). The difference is that the work is being done within a mutex as suppose to a server. The work to keep track of what priorities are being inherited is even easier than mutexs, since you have a process (the server) to just point to which process it has inherited, and a wait queue to store which process needs to be inherited next when the server wakes up the currently inherited process. -- Steve