Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751968AbbGMJ6I (ORCPT ); Mon, 13 Jul 2015 05:58:08 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:56131 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbbGMJ6F (ORCPT ); Mon, 13 Jul 2015 05:58:05 -0400 Date: Mon, 13 Jul 2015 11:57:57 +0200 From: Peter Zijlstra To: Christoph Lameter Cc: Chris Mason , Andy Lutomirski , "ksummit-discuss@lists.linuxfoundation.org" , "linux-kernel@vger.kernel.org" , Jens Axboe , Mathieu Desnoyers , Shaohua Li Subject: Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences Message-ID: <20150713095757.GW19282@twins.programming.kicks-ass.net> References: <20150709190916.GI1522@ret.masoncoding.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Content-Length: 1765 Lines: 38 On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote: > On Thu, 9 Jul 2015, Chris Mason wrote: > > > I think the topic is really interesting and we'll be able to get numbers > > from production workloads to help justify and compare different > > approaches. > > Ok that would be important. I also think that the approach may be used > in kernel to reduce the overhead of CONFIG_PREEMPT and also to implement > fast versions of this_cpu_ops for non x86 architectures and maybe even There is nothing stopping people from trying this in-kernel, in fact that would be lots easier as we do not have to commit to any one specific ABI for that. Also, I don't think we need a schedule check for the in-kernel usage, pure interrupt should be good enough, nobody should (want to) call schedule() while inside such a critical section, which leaves us with involuntary preemption, and those are purely interrupt driven. Now the 'problem' is finding these special regions fast, the easy solution is the same as the one proposed for userspace, one big section. That way the interrupt only has to check if the IP is inside this section which is minimal effort. The down side is that all percpu ops would then end up being full function calls. Which on some archs is indeed faster than disabling interrupts, but not by much I'm afraid. > optimize the x86 variants if interrupts also can detect critical sections > and restart at defined points. I really don't see how we can beat %GS prefixes with any such scheme. -- 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/