Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261731AbVDKIul (ORCPT ); Mon, 11 Apr 2005 04:50:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261736AbVDKIuk (ORCPT ); Mon, 11 Apr 2005 04:50:40 -0400 Received: from fmr20.intel.com ([134.134.136.19]:4756 "EHLO orsfmr005.jf.intel.com") by vger.kernel.org with ESMTP id S261731AbVDKIud convert rfc822-to-8bit (ORCPT ); Mon, 11 Apr 2005 04:50:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH] Priority Lists for the RT mutex Date: Mon, 11 Apr 2005 01:49:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Priority Lists for the RT mutex Thread-Index: AcU+cm/A/19DSUJbQhmvKRZ0dBFU3gAABjhg From: "Perez-Gonzalez, Inaky" To: "Ingo Molnar" Cc: "Sven-Thorsten Dietrich" , "Daniel Walker" , , "Steven Rostedt" , "Esben Nielsen" , "Joe Korty" X-OriginalArrivalTime: 11 Apr 2005 08:49:37.0241 (UTC) FILETIME=[6427AC90:01C53E73] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1374 Lines: 35 >From: Ingo Molnar [mailto:mingo@elte.hu] > >* Perez-Gonzalez, Inaky wrote: > >> >OTOH, deadlock detection is another issue. It's quite expensive and i'm >> >not sure we want to make it a runtime thing. But for fusyn's deadlock >> >detection and safe teardown on owner-exit is a must-have i suspect? >> >> Not really. Deadlock check is needed on PI, so it can be done at the >> same time (you have to walk the chain anyway). In any other case, it >> is an option you can request (or not). > >well, i was talking about the mutex code in PREEMPT_RT. There deadlock >detection is an optional debug feature. You dont _have_ to do deadlock >detection for the kernel's locks, and there's a difference in >performance. Big mouth'o mine :-| Let me re-phrase then: it is a must have only on PI, to make sure you don't have a loop when doing it. Maybe is a consequence of the algorithm I chose. -However- it should be possible to disable it in cases where you are reasonably sure it won't happen (such as kernel code). In any case, AFAIR, I still did not implement it. Was this more useful? -- Inaky - 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/