From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org
Cc: linux-tip-commits@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Davidlohr Bueso <dbueso@suse.de>,
x86@kernel.org
Subject: Re: [tip: locking/urgent] locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling
Date: Wed, 17 Mar 2021 09:43:20 -0400 [thread overview]
Message-ID: <85fbce04-c544-6041-6e7d-76f47b90e263@redhat.com> (raw)
In-Reply-To: <YFH9Pw3kwCZC1UTB@hirez.programming.kicks-ass.net>
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 <longman@redhat.com>
>> AuthorDate: Tue, 16 Mar 2021 11:31:16 -04:00
>> Committer: Ingo Molnar <mingo@kernel.org>
>> 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
next prev parent reply other threads:[~2021-03-17 13:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 15:31 [PATCH 0/4] locking/ww_mutex: Fix locktorture ww_mutex test problems Waiman Long
2021-03-16 15:31 ` [PATCH 1/4] locking/ww_mutex: Simplify use_ww_ctx & ww_ctx handling Waiman Long
2021-03-16 18:55 ` Davidlohr Bueso
2021-03-17 12:38 ` [tip: locking/urgent] " tip-bot2 for Waiman Long
2021-03-17 12:59 ` Peter Zijlstra
2021-03-17 13:43 ` Waiman Long [this message]
2021-03-17 13:55 ` Peter Zijlstra
2021-03-17 14:10 ` Waiman Long
2021-03-17 14:17 ` Peter Zijlstra
2021-03-17 14:33 ` Waiman Long
2021-03-16 15:31 ` [PATCH 2/4] locking/ww_mutex: Fix acquire/release imbalance in ww_acquire_init()/ww_acquire_fini() Waiman Long
2021-03-17 12:38 ` [tip: locking/urgent] " tip-bot2 for Waiman Long
2021-03-16 15:31 ` [PATCH 3/4] locking/ww_mutex: Treat ww_mutex_lock() like a trylock Waiman Long
2021-03-17 3:01 ` Davidlohr Bueso
2021-03-17 12:38 ` [tip: locking/urgent] " tip-bot2 for Waiman Long
2021-03-17 13:12 ` Peter Zijlstra
2021-03-17 13:31 ` Peter Zijlstra
2021-03-17 14:03 ` Waiman Long
2021-03-17 15:35 ` Waiman Long
2021-03-17 16:48 ` Peter Zijlstra
2021-03-17 17:40 ` Peter Zijlstra
2021-03-17 17:45 ` Peter Zijlstra
2021-03-17 18:32 ` Waiman Long
2021-03-17 19:58 ` Peter Zijlstra
2021-03-17 20:20 ` Waiman Long
2021-03-17 18:14 ` Waiman Long
2021-03-18 2:24 ` [PATCH 3/4] " Boqun Feng
2021-03-18 2:54 ` Waiman Long
2021-03-18 6:36 ` Boqun Feng
2021-03-16 15:31 ` [PATCH 4/4] locking/locktorture: Fix incorrect use of ww_acquire_ctx in ww_mutex test Waiman Long
2021-03-17 5:16 ` Davidlohr Bueso
2021-03-17 13:21 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85fbce04-c544-6041-6e7d-76f47b90e263@redhat.com \
--to=longman@redhat.com \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®