Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753648AbbGITJ5 (ORCPT ); Thu, 9 Jul 2015 15:09:57 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:39152 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753319AbbGITJt (ORCPT ); Thu, 9 Jul 2015 15:09:49 -0400 Date: Thu, 9 Jul 2015 15:09:16 -0400 From: Chris Mason To: Andy Lutomirski CC: "ksummit-discuss@lists.linuxfoundation.org" , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Mathieu Desnoyers , Jens Axboe , Shaohua Li Subject: Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences Message-ID: <20150709190916.GI1522@ret.masoncoding.com> Mail-Followup-To: Chris Mason , Andy Lutomirski , "ksummit-discuss@lists.linuxfoundation.org" , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Mathieu Desnoyers , Jens Axboe , Shaohua Li References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-09_10:2015-07-08,2015-07-09,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 33 On Thu, Jul 09, 2015 at 11:32:45AM -0700, Andy Lutomirski wrote: > Several people have suggested that Linux should provide users with a > lightweight mechanism that allows light-weight fancy per-cpu > operations. This could be used to implement free lists or counters > without any barriers or atomic operations, for example. > > There are at least three approaches floating around. Paul Turner > proposed a single block of userspace code that aborts if it's > preempted -- within that block, percpu variables can be used safely. > Mathieu Desnoyers proposed a more complex variant. I proposed a much > simpler approach of just offering percpu gs bases on x86, allowing > cmpxchg (as opposed to lock cmpxchg) to access percpu variables. > > None of these should be hard to implement, but it would be nice to > hash out whether the kernel should support such a mechanism at all > and, if so, what it would look like. [ added Jens and Shaohua ] We've started experimenting with these to cut overheads in a few critical places, and while we don't have numbers yet I really hope it won't take too long. 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. -chris -- 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/