Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758061Ab3DQTIV (ORCPT ); Wed, 17 Apr 2013 15:08:21 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:51496 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756580Ab3DQTIS (ORCPT ); Wed, 17 Apr 2013 15:08:18 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: <20130409222808.GC20739@home.goodmis.org> References: <20130228102452.15191.22673.stgit@patser> <20130228102502.15191.14146.stgit@patser> <1364900432.18374.24.camel@laptop> <515AF1C1.7080508@canonical.com> <1364921954.20640.22.camel@laptop> <1365076908.2609.94.camel@laptop> <20130404133123.GW2228@phenom.ffwll.local> <1365093662.2609.111.camel@laptop> <20130409222808.GC20739@home.goodmis.org> Date: Wed, 17 Apr 2013 21:08:17 +0200 Message-ID: Subject: Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2 From: Daniel Vetter To: Steven Rostedt Cc: Peter Zijlstra , Maarten Lankhorst , linux-arch@vger.kernel.org, x86@kernel.org, Linux Kernel Mailing List , dri-devel , "linaro-mm-sig@lists.linaro.org" , rob clark , Thomas Gleixner , Ingo Molnar , "linux-media@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1786 Lines: 38 On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote: > On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: >> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: >> > The thing is now that you're not expected to hold these locks for a >> > long >> > time - if you need to synchronously stall while holding a lock >> > performance >> > will go down the gutters anyway. And since most current >> > gpus/co-processors >> > still can't really preempt fairness isn't that high a priority, >> > either. >> > So we didn't think too much about that. >> >> Yeah but you're proposing a new synchronization primitive for the core >> kernel.. all such 'fun' details need to be considered, not only those >> few that bear on the one usecase. > > Which bares the question, what other use cases are there? Just stumbled over one I think: If we have a big graph of connected things (happens really often for video pipelines). And we want multiple users to use them in parallel. But sometimes a configuration change could take way too long and so would unduly stall a 2nd thread with just a global mutex, then per-object ww_mutexes would be a fit: You'd start with grabbing all the locks for the objects you want to change anything with, then grab anything in the graph that you also need to check. Thanks to loop detection and self-recursion this would all nicely work out, even for cyclic graphs of objects. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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/