From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218AbcAFIQv (ORCPT ); Wed, 6 Jan 2016 03:16:51 -0500 Received: from casper.infradead.org ([85.118.1.10]:40528 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751986AbcAFIQs (ORCPT ); Wed, 6 Jan 2016 03:16:48 -0500 Date: Wed, 6 Jan 2016 09:16:43 +0100 From: Peter Zijlstra To: One Thousand Gnomes Cc: ling.ma.program@gmail.com, waiman.long@hpe.com, mingo@redhat.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, ling.ml@alibaba-inc.com Subject: Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform Message-ID: <20160106081643.GS6344@twins.programming.kicks-ass.net> References: <1451549374-30875-1-git-send-email-ling.ma.program@gmail.com> <20160105211834.GR6344@twins.programming.kicks-ass.net> <20160105214227.3a2adcd2@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160105214227.3a2adcd2@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2016 at 09:42:27PM +0000, One Thousand Gnomes wrote: > > It suffers the typical problems all those constructs do; namely it > > wrecks accountability. > > That's "government thinking" ;-) - for most real users throughput is > more important than accountability. With the right API it ought to also > be compile time switchable. Its to do with having been involved with -rt. RT wants to do accountability for such things because of PI and sorts. > > But here that is compounded by the fact that you inject other people's > > work into 'your' lock region, thereby bloating lock hold times. Worse, > > afaict (from a quick reading) there really isn't a bound on the amount > > of work you inject. > > That should be relatively easy to fix but for this kind of lock you > normally get the big wins from stuff that is only a short amount of > executing code. The fairness your trade in the cases it is useful should > be tiny except under extreme load, where the "accountability first" > behaviour would be to fall over in a heap. > > If your "lock" involves a lot of work then it probably should be a work > queue or not using this kind of locking. Sure, but the fact that it was not even mentioned/considered doesn't give me a warm fuzzy feeling. > > And while its a cute collapse of an MCS lock and lockless list style > > work queue (MCS after all is a lockless list), saving a few cycles from > > the naive spinlock+llist implementation of the same thing, I really > > do not see enough justification for any of this. > > I've only personally dealt with such locks in the embedded space but > there it was a lot more than a few cycles because you go from Nah, what I meant was that you can do the same callback style construct with a llist and a spinlock. > The claim in the original post is 3x performance but doesn't explain > performance doing what, or which kernel locks were switched and what > patches were used. I don't find the numbers hard to believe for a big big > box, but I'd like to see the actual use case patches so it can be benched > with other workloads and also for latency and the like. Very much agreed, those claims need to be substantiated with actual patches using this thing and independently verified.