[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100413173941.GI13327@think>
Date: Tue, 13 Apr 2010 13:39:41 -0400
From: Chris Mason <chris.mason@...cle.com>
To: Manfred Spraul <manfred@...orfullife.com>
Cc: zach.brown@...cle.com, jens.axboe@...cle.com,
linux-kernel@...r.kernel.org, Nick Piggin <npiggin@...e.de>
Subject: Re: [PATCH 1/2] ipc semaphores: reduce ipc_lock contention in
semtimedop
On Tue, Apr 13, 2010 at 07:15:30PM +0200, Manfred Spraul wrote:
> Hi Chris,
>
>
> On 04/12/2010 08:49 PM, Chris Mason wrote:
> > /*
> >+ * when a semaphore is modified, we want to retry the series of operations
> >+ * for anyone that was blocking on that semaphore. This breaks down into
> >+ * a few different common operations:
> >+ *
> >+ * 1) One modification releases one or more waiters for zero.
> >+ * 2) Many waiters are trying to get a single lock, only one will get it.
> >+ * 3) Many modifications to the count will succeed.
> >+ *
> Have you thought about odd corner cases:
> Nick noticed the last time that it is possible to wait for arbitrary values:
> in one semop:
> - decrease semaphore 5 by 10
> - wait until semaphore 5 is 0
> - increase semaphore 5 by 10.
Do you mean within a single sop array doing all three of these? I don't
know if the sort is going to leave the three operations on semaphore 5
in the same order (it probably won't).
But I could change that by having it include the slot in the original
sop array in the sorting. That way if we have duplicate semnums in the
array, they will end up in the same position relative to each other in
the sorted result.
(ewwww ;)
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists