Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp546785pxf; Wed, 17 Mar 2021 10:12:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdwxOvqvoy1tsEBtHT+wsc3yqpGRW/sP0kOyDc+DBvhGYMAvK2PCg8AwLMu4IMuE8YO2mj X-Received: by 2002:a05:6402:b48:: with SMTP id bx8mr44868479edb.162.1616001157306; Wed, 17 Mar 2021 10:12:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616001157; cv=none; d=google.com; s=arc-20160816; b=XCFIECaV4aIWX0mFC+7IgZh6FqGxtSJeP4D7/evFC7Kq9tLoD6iQINuTsqcnkQF42s BMulUqhRftErPaHOKHXga00pqSZ7p7smERR1JfU+GmwQiqF9dqROGgJN/hO0OY+aKgpq Tww3/fLoAY20aw4FWMXhEfzgewb7jQpOuMYZODM4BGob3CozHR/WR3JVdKbwhMfrguT8 ka+WLjG4SMCCjYkzncfiT5zH/z3Z2WU8qsiewDltqM4UzzWx1VIrIrSbX6+kDoAZ6G3F JXIC1+mZOrmBU3afZRibY6tjZikqWdfaxVwczsPRvG38syxAbT4tnnk3DWjgZMX+Xts4 xo8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=J6W2NAAyf0FpcLn99G024NFc9PBWLRHCwNHkA7HcE9I=; b=L0sgxjolDAlDBF6ae8Lg66SV6mme+HbSvzPR11DizF7BnLliirbMJugW3w3GhLk6PF g95oRahe2cTrYMuNV9IJ2TkM4Vq2+u9rSipsHEMeNacgUTUe9n7sL4Qbr7m2LTJRNIwK IELnTl7oeqUHOOBOfPtF4UwAjXEqyVoLqdBCUEvuUCUDYzcgmV/djgrW4rbtbtehLSX8 dmD/CQ8w2k8Ctbf7JMcUNg/R247ZUbtV9LszV9GA5ddq8x1yy7zlnhvvS9yLbNvk8lJY xrx71ze3HQcrZQoMafwuFWLksdbuBV2XSmBy8YQfhXyVwRs38sMVqCsqPwksj6OgLiA2 MFhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fIvYRH8z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j9si16962333edw.509.2021.03.17.10.12.14; Wed, 17 Mar 2021 10:12:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fIvYRH8z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231209AbhCQNng (ORCPT + 99 others); Wed, 17 Mar 2021 09:43:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:26075 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231340AbhCQNn2 (ORCPT ); Wed, 17 Mar 2021 09:43:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615988608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J6W2NAAyf0FpcLn99G024NFc9PBWLRHCwNHkA7HcE9I=; b=fIvYRH8zZswK5Q4HWLQcbGi+2+k3jZxoHdSkth+b0Nc/qQi6NNSdF7djXaH9Hxdaf6QMR6 QVjtfdiM2g1W2LAr019AQQEYTfLn/B79FoECU77C8RZkCx+4YqRfO8Ck8YiX/R6opdi9TE EgV81bzqr7LRlJtqQJCKky2dIm4ucKU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-12-ceukJS8bOdiaPWc7vaRhjg-1; Wed, 17 Mar 2021 09:43:23 -0400 X-MC-Unique: ceukJS8bOdiaPWc7vaRhjg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6CF27108BD08; Wed, 17 Mar 2021 13:43:21 +0000 (UTC) Received: from llong.remote.csb (ovpn-117-171.rdu2.redhat.com [10.10.117.171]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2319610F1; Wed, 17 Mar 2021 13:43:20 +0000 (UTC) Subject: Re: [tip: locking/urgent] locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling To: Peter Zijlstra , linux-kernel@vger.kernel.org Cc: linux-tip-commits@vger.kernel.org, Ingo Molnar , Davidlohr Bueso , x86@kernel.org References: <20210316153119.13802-2-longman@redhat.com> <161598470257.398.5006518584847290113.tip-bot2@tip-bot2> From: Waiman Long Organization: Red Hat Message-ID: <85fbce04-c544-6041-6e7d-76f47b90e263@redhat.com> Date: Wed, 17 Mar 2021 09:43:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/17/21 8:59 AM, Peter Zijlstra wrote: > On Wed, Mar 17, 2021 at 12:38:22PM -0000, tip-bot2 for Waiman Long wrote: >> The following commit has been merged into the locking/urgent branch of tip: >> >> Commit-ID: 5de2055d31ea88fd9ae9709ac95c372a505a60fa >> Gitweb: https://git.kernel.org/tip/5de2055d31ea88fd9ae9709ac95c372a505a60fa >> Author: Waiman Long >> AuthorDate: Tue, 16 Mar 2021 11:31:16 -04:00 >> Committer: Ingo Molnar >> CommitterDate: Wed, 17 Mar 2021 09:56:44 +01:00 >> >> locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling >> >> The use_ww_ctx flag is passed to mutex_optimistic_spin(), but the >> function doesn't use it. The frequent use of the (use_ww_ctx && ww_ctx) >> combination is repetitive. >> >> In fact, ww_ctx should not be used at all if !use_ww_ctx. Simplify >> ww_mutex code by dropping use_ww_ctx from mutex_optimistic_spin() an >> clear ww_ctx if !use_ww_ctx. In this way, we can replace (use_ww_ctx && >> ww_ctx) by just (ww_ctx). > The reason this code was like this is because GCC could constant > propagage use_ww_ctx but could not do the same for ww_ctx (since that's > external). > > Please double check generated code to make sure you've not introduced a > bunch of extra branches. > I see, but this patch just replaces (use_ww_ctx && ww_ctx) by (ww_ctx). Even if constant propagation isn't happening for ww_ctx, gcc shouldn't generate any worse code wrt ww_ctx. It could be that the generated machine code are more or less the same, but the source code will look cleaner with just one variable in the conditional clauses. Using gcc 8.4.1, the generated __mutex_lock function has the same size (with last instruction at offset +5179) with or without this patch. Well, you can say that this patch is an no-op wrt generated code. Cheers, Longman