Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757180Ab3CFXKt (ORCPT ); Wed, 6 Mar 2013 18:10:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14522 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754857Ab3CFXKs (ORCPT ); Wed, 6 Mar 2013 18:10:48 -0500 Message-ID: <5137CCB2.4050506@redhat.com> Date: Wed, 06 Mar 2013 18:09:38 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Linus Torvalds CC: Davidlohr Bueso , Emmanuel Benisty , "Vinod, Chegu" , "Low, Jason" , Peter Zijlstra , "H. Peter Anvin" , Andrew Morton , aquini@redhat.com, Michel Lespinasse , Ingo Molnar , Larry Woodman , Linux Kernel Mailing List , Steven Rostedt , Thomas Gleixner , hhuang@redhat.com Subject: Re: [PATCH v2 7/4] ipc: fine grained locking for semtimedop References: <1362476149.2225.50.camel@buesod1.americas.hpqcorp.net> <20130306171546.63471bc0@cuia.bos.redhat.com> In-Reply-To: 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: 1677 Lines: 35 On 03/06/2013 05:57 PM, Linus Torvalds wrote: > On Wed, Mar 6, 2013 at 5:15 PM, Rik van Riel wrote: >> >> If the call is a semop manipulating just one semaphore in >> an array with multiple semaphores, the read/write lock for >> the semaphore array is taken in shared (read) mode, and the >> individual semaphore's lock is taken. > > You know, we do something like this already elsewhere, and I think we > do it slightly better. See the mm_take_all_locks() logic in mm/mmap.c. That would work. If we are about to do one of the uncommon operations,or sma->complex_count is set, we need to take the outer lock and all of the inner locks. The only complication would be interactions with the non-semaphore code in ipc/util.c, which manipulates the kern_ipc_perm structures, which are part of the sem_array structure. > That said, judging by your numbers, your read-write lock seems to work > fine too, even though I'd worry about cacheline ping-pong (but not > contention) on the readers. So it doesn't seem optimal, but it sure as > hell seems better than what we do now ;) I can take a stab at implementing the take_all_locks approach tomorrow. If things turn out to be easier than I fear, I will send an updated patch. If the resulting changes to the rest of ipc/ turn out to be too ugly to live, the rwsem performance is likely to be good enough for a while, and I'll just send an email without a patch :) -- 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/