Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751483Ab3CASvJ (ORCPT ); Fri, 1 Mar 2013 13:51:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57764 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779Ab3CASvG (ORCPT ); Fri, 1 Mar 2013 13:51:06 -0500 Message-ID: <5130F886.2070009@redhat.com> Date: Fri, 01 Mar 2013 13:50:46 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Davidlohr Bueso CC: Linus Torvalds , Linux Kernel Mailing List , Thomas Gleixner , Steven Rostedt , "Vinod, Chegu" , "Low, Jason" , linux-tip-commits@vger.kernel.org, Peter Zijlstra , "H. Peter Anvin" , Andrew Morton , aquini@redhat.com, Michel Lespinasse , Ingo Molnar , Larry Woodman Subject: Re: [tip:core/locking] x86/smp: Move waiting on contended ticket lock out of line References: <20130206150403.006e5294@cuia.bos.redhat.com> <512E376D.70105@redhat.com> <512E6443.9050603@redhat.com> <512E80E3.7060800@redhat.com> <512EC7F0.60103@redhat.com> <1362024397.1867.28.camel@buesod1.americas.hpqcorp.net> <512F7429.4020103@redhat.com> <512FC89B.6030507@redhat.com> <512FDC82.2060606@redhat.com> <51304DDA.40808@redhat.com> <1362161912.12277.10.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1362161912.12277.10.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2217 Lines: 53 On 03/01/2013 01:18 PM, Davidlohr Bueso wrote: > On Fri, 2013-03-01 at 01:42 -0500, Rik van Riel wrote: >> On 02/28/2013 06:09 PM, Linus Torvalds wrote: >> >>> So I almost think that *everything* there in the semaphore code could >>> be done under RCU. The actual spinlock doesn't seem to much matter, at >>> least for semaphores. The semaphore values themselves seem to be >>> protected by the atomic operations, but I might be wrong about that, I >>> didn't even check. >> >> Checking try_atomic_semop and do_smart_update, it looks like neither >> is using atomic operations. That part of the semaphore code would >> still benefit from spinlocks. > > Agreed. If we assume that calls to semctl with more than one semaphore operator are rare, we could do something smarter here. We could turn the outer spinlock into an rwlock. If we are doing a call that modifies the outer structure, or multiple semops at once, we take the lock exclusively. If we want to do just one semop, we can take the lock in shared mode. Then each semaphore inside would have its own spinlock, and we lock just that one. Of course, that would just add overhead to the case where a semaphore block has just one semaphore in it, so I'm not sure this would be worthwhile at all... >> The way the code handles a whole batch of semops all at once, >> potentially to multiple semaphores at once, and with the ability >> to undo all of the operations, it looks like the spinlock will >> still need to be per block of semaphores. >> >> I guess the code may still benefit from Michel's locking code, >> after the permission stuff has been moved from under the spinlock. > > How about splitting ipc_lock()/ipc_lock_control() in two calls: one to > obtain the ipc object (rcu_read_lock + idr_find), which can be called > when performing the permissions and security checks, and another to > obtain the ipcp->lock [q_]spinlock when necessary. That is what I am working on now. -- All rights reversed -- 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/