Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262346AbUKDSML (ORCPT ); Thu, 4 Nov 2004 13:12:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262349AbUKDSKt (ORCPT ); Thu, 4 Nov 2004 13:10:49 -0500 Received: from mail.timesys.com ([65.117.135.102]:23185 "EHLO exchange.timesys.com") by vger.kernel.org with ESMTP id S262352AbUKDSEL (ORCPT ); Thu, 4 Nov 2004 13:04:11 -0500 Message-ID: <418A7BFB.6020501@timesys.com> Date: Thu, 04 Nov 2004 13:59:07 -0500 From: john cooper User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ingo Molnar CC: Mark_H_Johnson@raytheon.com, Karsten Wiese , Bill Huey , Adam Heath , "K.R. Foley" , linux-kernel@vger.kernel.org, Florian Schmidt , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Thomas Gleixner , Michal Schmidt , john cooper Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 References: <20041104163012.GA3498@elte.hu> <20041104163254.GA3810@elte.hu> In-Reply-To: <20041104163254.GA3810@elte.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2004 17:58:23.0703 (UTC) FILETIME=[E0968E70:01C4C297] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1551 Lines: 37 Ingo Molnar wrote: > * Ingo Molnar wrote: > > >>X should be scheduled on the other CPU just fine. Only per-CPU kernel >>threads (which are affine to their particular CPU) are affected by >>this problem - ordinary tasks not. I.e. the system threads that have >>/0 and /1 in their name. In theory you should not even need to chrt >>the hardirq threads, those should schedule fine too. > > > plus there's the 'priority inheritance dependency-chain closure' bug > noticed by John Cooper - that should only affect the latency of RT tasks > though. This is a fairly gnarly problem to address. The obvious solution is to hold spinlocks in the mutexes as the dependency tree is atomically traversed. However this will deadlock under MP due to the unpredictable order of mutexes traversed. If the dependency chain is not traversed (and semantics applied) atomically, races exist which cause promotion decisions to be made on [now] stale data. The simple solution is a global spinlock which doesn't scale well under MP. Another possible solution would be conditional traversal of the chain where contention within the chain under foot (from another chain walker) causes the traversal to abort and retry. Though this has the down side of being nondeterministic. -- john.cooper@timesys.com - 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/