Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752869AbbGNUBV (ORCPT ); Tue, 14 Jul 2015 16:01:21 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:35754 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751900AbbGNUBU (ORCPT ); Tue, 14 Jul 2015 16:01:20 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150709190916.GI1522@ret.masoncoding.com> <20150713095757.GW19282@twins.programming.kicks-ass.net> From: Andy Lutomirski Date: Tue, 14 Jul 2015 13:00:59 -0700 Message-ID: Subject: Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences To: Christoph Lameter Cc: Peter Zijlstra , Chris Mason , "ksummit-discuss@lists.linuxfoundation.org" , "linux-kernel@vger.kernel.org" , Jens Axboe , Mathieu Desnoyers , Shaohua Li Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1535 Lines: 39 On Mon, Jul 13, 2015 at 7:01 AM, Christoph Lameter wrote: > On Mon, 13 Jul 2015, Peter Zijlstra wrote: > >> 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. > > Well one could move the entire functions that are using these ops into the > special sections. That is certainly an area requiring much more thought. Hmm. > >> > 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. > > We may be able to avoid RMV sequences which allows the processor to better > schedule operations. True, but cmpxchg is, surprisingly, pretty fast. Crazy thought: At the risk of proposing something ridiculous, what if we had per-cpu memory mappings? We could do this at the cost of up to 2kB of memcpy whenever we switch mms. Expensive but maybe not a showstopper. --Andy -- 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/