From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755265Ab0KZRBd (ORCPT ); Fri, 26 Nov 2010 12:01:33 -0500 Received: from mail-wy0-f174.google.com ([74.125.82.174]:53556 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751627Ab0KZRBc (ORCPT ); Fri, 26 Nov 2010 12:01:32 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=VDJkNPUVNeFT/j/s0D5RxwCvi5R9ChmBmfiZzgbYdFny1S0Md74OWdeWoiQisI7LaK p3whzL2aduq5k5JOlUQjx+kv7e52G0pI6ctd1gj25U+Z7Pu9q/4cE3GFjMDlOkXFt1Kq dsQclYqM2MqKhqCZuDiapRKrPez8XhCdgCE0k= Subject: Re: [thiscpuops upgrade 08/10] percpu: generic this_cpu_cmpxchg() and this_cpu_cmpxchg_double support From: Eric Dumazet To: Tejun Heo Cc: Christoph Lameter , akpm@linux-foundation.org, Pekka Enberg , linux-kernel@vger.kernel.org, Mathieu Desnoyers In-Reply-To: <4CEFE71F.5090303@kernel.org> References: <20101123235139.908255844@linux.com> <20101123235200.582485207@linux.com> <4CEFE583.8070103@kernel.org> <1290790569.2855.254.camel@edumazet-laptop> <4CEFE71F.5090303@kernel.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 26 Nov 2010 18:01:27 +0100 Message-ID: <1290790887.2855.260.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le vendredi 26 novembre 2010 à 17:58 +0100, Tejun Heo a écrit : > On 11/26/2010 05:56 PM, Eric Dumazet wrote: > > Le vendredi 26 novembre 2010 à 17:51 +0100, Tejun Heo a écrit : > >> On 11/24/2010 12:51 AM, Christoph Lameter wrote: > >>> +/* > >>> + * cmpxchg_double replaces two adjacent scalars at once. The first parameter > >>> + * passed is a percpu pointer, not a scalar like the other this_cpu > >>> + * operations. This is so because the function operates on two scalars > >>> + * (must be of same size). A truth value is returned to indicate success or > >>> + * failure (since a double register result is difficult to handle). > >>> + * There is very limited hardware support for these operations. So only certain > >>> + * sizes may work. > >>> + */ > >>> +#define __this_cpu_generic_cmpxchg_double(pcp, oval1, oval2, nval1, nval2) \ > >> > >> Ah... this is scary. If it proves to be useful enough, sure, but > >> otherwise I'd like to avoid it. > > > > This is mandatory for several lockless algos, dont be afraid, its a > > single instruction ;) > > Thanks for holding my hands. :-) > > What I'm afraid of is generic code switching to use it in very hot > paths when a lot of archs can't actually do it leading to performance > regressions. Is this something which is available on most archs? > I would say cmpxchg() has the same problem, some arches dont have a native instruction, yet we use it in some paths.