From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752525AbcAFLZp (ORCPT ); Wed, 6 Jan 2016 06:25:45 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:52770 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752210AbcAFLZk (ORCPT ); Wed, 6 Jan 2016 06:25:40 -0500 Date: Wed, 6 Jan 2016 11:24:50 +0000 From: One Thousand Gnomes To: Peter Zijlstra 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: <20160106112450.6c5ad08b@lxorguk.ukuu.org.uk> In-Reply-To: <20160106082106.GU6373@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> <20160106081643.GS6344@twins.programming.kicks-ass.net> <20160106082106.GU6373@twins.programming.kicks-ass.net> Organization: Intel Corporation X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 6 Jan 2016 09:21:06 +0100 Peter Zijlstra wrote: > On Wed, Jan 06, 2016 at 09:16:43AM +0100, Peter Zijlstra wrote: > > 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. > > Also, real people really do care about latency too, very bad worst case > spikes to upset things. Some yes - I'm familiar with the way some of the big financial number crunching jobs need this. There are also people who instead care a lot about throughput. Anything like this needs to end up with an external API which looks the same whether the work is done via one thread or the other. Alan