From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C99D92C00BB for ; Tue, 11 Feb 2014 13:45:53 +1100 (EST) Message-ID: <1392086660.3996.50.camel@pasglop> Subject: Re: [PATCH v2] powerpc ticket locks From: Benjamin Herrenschmidt To: Torsten Duwe Date: Tue, 11 Feb 2014 13:44:20 +1100 In-Reply-To: <20140210155217.GF2107@lst.de> References: <20140207165801.GC2107@lst.de> <1392001823.3996.21.camel@pasglop> <20140210155217.GF2107@lst.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: Tom Musta , Peter Zijlstra , Linus Torvalds , linux-kernel@vger.kernel.org, Paul Mackerras , Anton Blanchard , Scott Wood , "Paul E. McKenney" , linuxppc-dev@lists.ozlabs.org, Ingo Molnar , Al Viro List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , (Linus, Al, a question for you down there about lockref "ref" size) On Mon, 2014-02-10 at 16:52 +0100, Torsten Duwe wrote: > What if I squeeze the bits a little? > 4k vCPUs, and 256 physical, as a limit to stay within 32 bits? > At the cost that unlock may become an ll/sc operation again. > I could think about a trick against that. > But alas, hw_cpu_id is 16 bit, which makes a lookup table neccessary :-/ > > Doing another round of yields for lockrefs now doesn't > sound so bad any more. So, the ticketpair has to be 16:16 so we can avoid the atomic on unlock That leaves us with 32 bits to put the ref and the owner. The question is how big the ref really has to be and can we have a reasonable failure mode if it overflows ? If we limit ourselves to, for example, 16-bit for the ref in lockref, then we can have the second 32-bit split between the owner and the ref. If we limit ourselves to 4k CPUs, then we get 4 more bits of ref ... So the question is, is it reasonable to have the ref smaller than 32-bit... Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752542AbaBKCqM (ORCPT ); Mon, 10 Feb 2014 21:46:12 -0500 Received: from gate.crashing.org ([63.228.1.57]:53339 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751779AbaBKCqI (ORCPT ); Mon, 10 Feb 2014 21:46:08 -0500 Message-ID: <1392086660.3996.50.camel@pasglop> Subject: Re: [PATCH v2] powerpc ticket locks From: Benjamin Herrenschmidt To: Torsten Duwe Cc: Paul Mackerras , Anton Blanchard , "Paul E. McKenney" , Peter Zijlstra , Scott Wood , Tom Musta , Ingo Molnar , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Linus Torvalds , Al Viro Date: Tue, 11 Feb 2014 13:44:20 +1100 In-Reply-To: <20140210155217.GF2107@lst.de> References: <20140207165801.GC2107@lst.de> <1392001823.3996.21.camel@pasglop> <20140210155217.GF2107@lst.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Linus, Al, a question for you down there about lockref "ref" size) On Mon, 2014-02-10 at 16:52 +0100, Torsten Duwe wrote: > What if I squeeze the bits a little? > 4k vCPUs, and 256 physical, as a limit to stay within 32 bits? > At the cost that unlock may become an ll/sc operation again. > I could think about a trick against that. > But alas, hw_cpu_id is 16 bit, which makes a lookup table neccessary :-/ > > Doing another round of yields for lockrefs now doesn't > sound so bad any more. So, the ticketpair has to be 16:16 so we can avoid the atomic on unlock That leaves us with 32 bits to put the ref and the owner. The question is how big the ref really has to be and can we have a reasonable failure mode if it overflows ? If we limit ourselves to, for example, 16-bit for the ref in lockref, then we can have the second 32-bit split between the owner and the ref. If we limit ourselves to 4k CPUs, then we get 4 more bits of ref ... So the question is, is it reasonable to have the ref smaller than 32-bit... Cheers, Ben.