From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261597AbULIUBr (ORCPT ); Thu, 9 Dec 2004 15:01:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261598AbULIUBq (ORCPT ); Thu, 9 Dec 2004 15:01:46 -0500 Received: from mail.timesys.com ([65.117.135.102]:960 "EHLO exchange.timesys.com") by vger.kernel.org with ESMTP id S261597AbULIUBk (ORCPT ); Thu, 9 Dec 2004 15:01:40 -0500 Message-ID: <41B8AE75.2090905@timesys.com> Date: Thu, 09 Dec 2004 14:58:45 -0500 From: john cooper User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Esben Nielsen CC: Mark_H_Johnson@raytheon.com, Florian Schmidt , Amit Shah , Karsten Wiese , Bill Huey , Adam Heath , emann@mrv.com, Gunther Persoons , "K.R. Foley" , linux-kernel@vger.kernel.org, Ingo Molnar , Fernando Pablo Lopez-Lezcano , Lee Revell , Rui Nuno Capela , Shane Shrybman , Thomas Gleixner , Michal Schmidt , john cooper Subject: Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2004 19:54:10.0046 (UTC) FILETIME=[D963A1E0:01C4DE28] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Esben Nielsen wrote: > Muteces are also an overhead. There must be a lot of locks in the system > which can safely be transfered back to raw spinlocks as the locking time > is in the same order of the locking time internally in a mutex. There is > no perpose of using a mutex instead of a raw spinlock if the region being > locked is shorter or about the same as the job of handling the mutex > internals and rescheduling (twice)! That will certainly be the case in some scenarios. It seems useful for the mutex user to have a means to advice of the anticipated usage (hold time). The other [perhaps additional] means of adaptation would be Solaris-style where a failed mutex acquisition attempt would spin rather than block the caller if the mutex owner is currently running on some other cpu. The rationale being the spin wait time is less overhead compared with two context switches. Though I'd expect this ideal has been batted around here before. -john -- john.cooper@timesys.com