Date: Sat, 26 Mar 2005 20:11:22 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Esben Nielsen <simlo@phys.au.dk>, linux-kernel@vger.kernel.org
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Message-ID: <20050326191122.GA8144@elte.hu>
References: <20050324113912.GA20911@elte.hu> <Pine.OSF.4.05.10503242307330.25274-100000@da410.phys.au.dk> <20050325061907.GA20242@elte.hu> <Pine.LNX.4.58.0503261125420.27746@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0503261125420.27746@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1085
Lines: 25


* Steven Rostedt <rostedt@goodmis.org> wrote:

> > i think this should be covered by the 'unschedule/unwakeup' feature,
> > mentioned in the latest mails.
> 
> The first implementation would probably just be the setting of a 
> "pending owner" bit. But the better one may be to unschedule. But, 
> what would the overhead be for unscheduling. Since you need to grab 
> the run queue locks for that. This might make for an interesting case 
> study. The waking up of a process who had the lock stolen may not 
> happen that much.  The lock stealing, would (as I see in my runs) 
> happen quite a bit though. But on UP, the waking of the robbed owner, 
> would never happen, unless it also owned a lock that a higher priority 
> process wanted.

yeah, lets skip the unscheduling for now, the 'pending owner' bit is the 
important one.

	Ingo
-
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/