From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932215AbWGXQot (ORCPT ); Mon, 24 Jul 2006 12:44:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932212AbWGXQot (ORCPT ); Mon, 24 Jul 2006 12:44:49 -0400 Received: from www.osadl.org ([213.239.205.134]:63181 "EHLO mail.tglx.de") by vger.kernel.org with ESMTP id S932215AbWGXQos (ORCPT ); Mon, 24 Jul 2006 12:44:48 -0400 Date: Mon, 24 Jul 2006 18:44:49 +0200 Message-ID: <87odvflzpa.wl%tglx@linutronix.de> From: Thomas Gleixner To: Steven Rostedt Cc: Esben Nielsen , Ingo Molnar , Thomas Gleixner , LKML , "Duetsch, Thomas LDE1" Subject: Re: [RT] rt priority losing In-Reply-To: <1153759042.11295.10.camel@localhost.localdomain> References: <1153755660.4002.137.camel@localhost.localdomain> <1153759042.11295.10.camel@localhost.localdomain> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 24 Jul 2006 12:37:22 -0400, Steven Rostedt wrote: > > > So this can be a problem, if the softirq function holds a lock of a high > > > priority task, and is running boosted. If another timer goes off with a > > > lower priority, we can lower the priority of the softirqd and lose the > > > inherited priority that it was running at. > > > > There is a check for that inside setscheduler(): > > p->prio = rt_mutex_getprio(p); > > OK, you are right about this. The PI chain should not be affected. But > this could still be a problem if the softirq was running at a high prio > for a task when a lower prio callback needs to be made. It looks like > timer is removed from the base before the function runs. So when the > interrupt looks at the base to determine the priority to set it at, it > might actually lower the priority of a running hrtimer thread. The correct solution is to run the callback in the context of the thread which will receive it and get rid of the softirq. I experimented with this already, but its more than a saturday afternoon project. tglx