From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A2D49C3DA7D for ; Thu, 5 Jan 2023 13:05:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DDDC710E716; Thu, 5 Jan 2023 13:04:58 +0000 (UTC) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7341A10E715 for ; Thu, 5 Jan 2023 13:04:54 +0000 (UTC) Received: by mail-wr1-x42a.google.com with SMTP id w1so23939067wrt.8 for ; Thu, 05 Jan 2023 05:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=OMl2z0bEVkQjBng9NmxI8H9oWdCOX+1jSoysVqvl5eUq0fH3zSvu0BR5H+deKbN8kC rsyD2oEp3IZDcF1WGL7zVwvFUrMkRoxAcIg3Ofa5uc0GywdmZ67j83ZBtB4kPfJGsNyP Kr3CyQCHYSr0tCSdT9C0hS7z6Vb2IpNMetTLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=pfzbnH6juYmYii5vqdr2amsHNsfEEL8UduNhtIH/mgmFydi8/cloaGgYJdoZC4ZSMo U5MWB7ArMJlu9rgcW3runutpDNdqpw2LfjvCRMZ59lE/pM9e3p1OdgfIfA3Ipw5ANYg1 QqiUVipczFC9bn72P8dhPBsPZ1rmmiYkd2WdAhh3LtVnjIx2Rz1H4QHBTL620tyD0fH9 B+CYocWEdFnUDc2OZ9OhyF1G4VhRiwMmGlcJ0AwAZ7ikv7SAwgxHMWA8eJLWNjnSfDQs 70FLo6p7DnJ14yXwOxlqIb8ShXWDKAcFM7U33smdUMx7SYkzjAT/aUdY8qjSCFVXYvuT 19bw== X-Gm-Message-State: AFqh2koe5xhh+1QZGucvDLRprz8oCeUxVl9EwCA2QvW/7blyTrZCa3il QaLvR/wEwiFbObQ4Pf1eA+mPsg== X-Google-Smtp-Source: AMrXdXtFVgsClYWQ/F/H3Fu9zHMZcwy4NMo0QmdJvkOV/usH8nN5KK69iAUk4NcI/VpNOKleze4rpQ== X-Received: by 2002:adf:e743:0:b0:242:63de:2f5b with SMTP id c3-20020adfe743000000b0024263de2f5bmr34768293wrn.6.1672923892964; Thu, 05 Jan 2023 05:04:52 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q5-20020adfcd85000000b002366553eca7sm36657442wrj.83.2023.01.05.05.04.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 05:04:51 -0800 (PST) Date: Thu, 5 Jan 2023 14:04:49 +0100 From: Daniel Vetter To: David Laight Message-ID: Mail-Followup-To: David Laight , 'Andrzej Hajda' , "linux-kernel@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , Tvrtko Ursulin , Arnd Bergmann , Andi Shyti , Rodrigo Vivi , Andrew Morton , Andy Shevchenko References: <20221209154843.4162814-1-andrzej.hajda@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.19.0-2-amd64 Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , 'Andrzej Hajda' , Rodrigo Vivi , Andrew Morton , Andy Shevchenko Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Dec 12, 2022 at 09:38:12AM +0000, David Laight wrote: > From: Andrzej Hajda > > Sent: 09 December 2022 15:49 > > > > The pattern of setting variable with new value and returning old > > one is very common in kernel. Usually atomicity of the operation > > is not required, so xchg seems to be suboptimal and confusing in > > such cases. Since name xchg is already in use and __xchg is used > > in architecture code, proposition is to name the macro exchange. > > Dunno, if it is non-atomic then two separate assignment statements > is decidedly more obvious and needs less brain cells to process. > Otherwise someone will assume 'something clever' is going on > and the operation is atomic. Yes, this also my take. The i915 code that uses this to excess is decidely unreadable imo, and the macro should simply be replaced by open-coded versions. Not moved into shared headers where even more people can play funny games with it. I think swap() is a standard idiom in C, this one here just isn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 64615C3DA7D for ; Thu, 5 Jan 2023 13:04:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 673A810E715; Thu, 5 Jan 2023 13:04:56 +0000 (UTC) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7439D10E716 for ; Thu, 5 Jan 2023 13:04:54 +0000 (UTC) Received: by mail-wr1-x432.google.com with SMTP id r2so1235063wrv.7 for ; Thu, 05 Jan 2023 05:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=OMl2z0bEVkQjBng9NmxI8H9oWdCOX+1jSoysVqvl5eUq0fH3zSvu0BR5H+deKbN8kC rsyD2oEp3IZDcF1WGL7zVwvFUrMkRoxAcIg3Ofa5uc0GywdmZ67j83ZBtB4kPfJGsNyP Kr3CyQCHYSr0tCSdT9C0hS7z6Vb2IpNMetTLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=nzoVzLURLTw3y9KmxufsbjHuK4XXLTC83WUJ57qtO6HSMzuqXJFbiyHpD5tHcdJGgu bqT/ph+fAA7ZrR39dWJMR3FA77RA/mNyR5QJ99Bp0aUgBcXk77IBSo4GzvLtrX+v7GGp jmGcUbFiGPrvAPDfw1hbSotzJ4eKKjEGPriWXBVDaRQ/ChC1jdOk92zm9FkTvwbmIm+0 BZw2o9QdJoi2ZupXgs1Kuva9s050m/bzBZYL9AB+pYR9acG3Gc2Hzdws5ajnGoFo15Jr 6H/TUuVJTIcMC0ihxjG4yfXeL9ZgjRug6JJx+NDGmiCaxNlMcunGcooFJFVed9bqkIaO isdA== X-Gm-Message-State: AFqh2kppBU0KkVL+NdOU+nY4LaTr4AMl/PRUoTealL+4zAsZVxd52p0n wwLZvLDwaY7h7/VsyADgnHt8Fw== X-Google-Smtp-Source: AMrXdXtFVgsClYWQ/F/H3Fu9zHMZcwy4NMo0QmdJvkOV/usH8nN5KK69iAUk4NcI/VpNOKleze4rpQ== X-Received: by 2002:adf:e743:0:b0:242:63de:2f5b with SMTP id c3-20020adfe743000000b0024263de2f5bmr34768293wrn.6.1672923892964; Thu, 05 Jan 2023 05:04:52 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q5-20020adfcd85000000b002366553eca7sm36657442wrj.83.2023.01.05.05.04.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 05:04:51 -0800 (PST) Date: Thu, 5 Jan 2023 14:04:49 +0100 From: Daniel Vetter To: David Laight Subject: Re: [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Message-ID: Mail-Followup-To: David Laight , 'Andrzej Hajda' , "linux-kernel@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , Tvrtko Ursulin , Arnd Bergmann , Andi Shyti , Rodrigo Vivi , Andrew Morton , Andy Shevchenko References: <20221209154843.4162814-1-andrzej.hajda@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.19.0-2-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tvrtko Ursulin , Andi Shyti , Arnd Bergmann , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , 'Andrzej Hajda' , Rodrigo Vivi , Andrew Morton , Andy Shevchenko Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Dec 12, 2022 at 09:38:12AM +0000, David Laight wrote: > From: Andrzej Hajda > > Sent: 09 December 2022 15:49 > > > > The pattern of setting variable with new value and returning old > > one is very common in kernel. Usually atomicity of the operation > > is not required, so xchg seems to be suboptimal and confusing in > > such cases. Since name xchg is already in use and __xchg is used > > in architecture code, proposition is to name the macro exchange. > > Dunno, if it is non-atomic then two separate assignment statements > is decidedly more obvious and needs less brain cells to process. > Otherwise someone will assume 'something clever' is going on > and the operation is atomic. Yes, this also my take. The i915 code that uses this to excess is decidely unreadable imo, and the macro should simply be replaced by open-coded versions. Not moved into shared headers where even more people can play funny games with it. I think swap() is a standard idiom in C, this one here just isn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93605C54E76 for ; Thu, 5 Jan 2023 13:05:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234035AbjAENFQ (ORCPT ); Thu, 5 Jan 2023 08:05:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234094AbjAENEz (ORCPT ); Thu, 5 Jan 2023 08:04:55 -0500 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FD1C5AC7E for ; Thu, 5 Jan 2023 05:04:54 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id co23so36082370wrb.4 for ; Thu, 05 Jan 2023 05:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=OMl2z0bEVkQjBng9NmxI8H9oWdCOX+1jSoysVqvl5eUq0fH3zSvu0BR5H+deKbN8kC rsyD2oEp3IZDcF1WGL7zVwvFUrMkRoxAcIg3Ofa5uc0GywdmZ67j83ZBtB4kPfJGsNyP Kr3CyQCHYSr0tCSdT9C0hS7z6Vb2IpNMetTLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LsZ32dv/OC+Nb4ftoKd68ybVYKMb6ALfR6sxEPmUBK0=; b=tnkFc4r+jiC3+2cDbfnslgT7lQHxwR5wZUWEpYmFA2JvtdkG2g8Ut8Mr8Jxwk10uCm tvCfngIN1Bg3o34d+Tvi+5jX0PE5PQW0aFo9szt3JHtHvtYo9cr/bV+9z2inKW4lvmJC MevdN6oT4Bj3IW6Iga+8b+5uKvph9OWZMZHBl5NrKjBsb6lOtVSxqTrePR1Nag063LH2 Uz3ONg4JE9oVx6ZYzCpzG2UgLERIqWDdat9DAFotxPfAMEGn1vU69OJuvZ1UNCTcCZ4O BF88tU4qTgmpxk7S9ESxqK9GslbB4Na+IToOo4btb9r+iCk6ekVREKyqkwJSN1fAFFbC NvOQ== X-Gm-Message-State: AFqh2koyY/P+4SLwHiqetfFCE5dHBRdHDFY6FaTjELlZMQdiSmnrxfLh WpzT5FWaD+r0k4tmjaQ8aUW0I0OidmOiR/cN X-Google-Smtp-Source: AMrXdXtFVgsClYWQ/F/H3Fu9zHMZcwy4NMo0QmdJvkOV/usH8nN5KK69iAUk4NcI/VpNOKleze4rpQ== X-Received: by 2002:adf:e743:0:b0:242:63de:2f5b with SMTP id c3-20020adfe743000000b0024263de2f5bmr34768293wrn.6.1672923892964; Thu, 05 Jan 2023 05:04:52 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q5-20020adfcd85000000b002366553eca7sm36657442wrj.83.2023.01.05.05.04.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jan 2023 05:04:51 -0800 (PST) Date: Thu, 5 Jan 2023 14:04:49 +0100 From: Daniel Vetter To: David Laight Cc: 'Andrzej Hajda' , "linux-kernel@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , Tvrtko Ursulin , Arnd Bergmann , Andi Shyti , Rodrigo Vivi , Andrew Morton , Andy Shevchenko Subject: Re: [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Message-ID: Mail-Followup-To: David Laight , 'Andrzej Hajda' , "linux-kernel@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , Tvrtko Ursulin , Arnd Bergmann , Andi Shyti , Rodrigo Vivi , Andrew Morton , Andy Shevchenko References: <20221209154843.4162814-1-andrzej.hajda@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.19.0-2-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 12, 2022 at 09:38:12AM +0000, David Laight wrote: > From: Andrzej Hajda > > Sent: 09 December 2022 15:49 > > > > The pattern of setting variable with new value and returning old > > one is very common in kernel. Usually atomicity of the operation > > is not required, so xchg seems to be suboptimal and confusing in > > such cases. Since name xchg is already in use and __xchg is used > > in architecture code, proposition is to name the macro exchange. > > Dunno, if it is non-atomic then two separate assignment statements > is decidedly more obvious and needs less brain cells to process. > Otherwise someone will assume 'something clever' is going on > and the operation is atomic. Yes, this also my take. The i915 code that uses this to excess is decidely unreadable imo, and the macro should simply be replaced by open-coded versions. Not moved into shared headers where even more people can play funny games with it. I think swap() is a standard idiom in C, this one here just isn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch