[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211008032518.1298372-1-yanfei.xu@windriver.com>
Date: Fri, 8 Oct 2021 11:25:18 +0800
From: Yanfei Xu <yanfei.xu@...driver.com>
To: peterz@...radead.org, mingo@...hat.com, will@...nel.org,
longman@...hat.com, boqun.feng@...il.com
Cc: linux-kernel@...r.kernel.org
Subject: [PATCH v2] locking/mutex: remove rcu_read_lock/unlock as we already disabled preemption
preempt_disable/enable() is equal to RCU read-side crital section,
and the mutex lock slowpath disabled the preemption for the optimistic
spinning code. Let's remove the rcu_read_lock/unlock for saving some
cycles in hot codes.
Signed-off-by: Yanfei Xu <yanfei.xu@...driver.com>
---
v1->v2: fix the incorrect comment in code and commit message.
thanks for WaiMan's suggestion.
BTW, sorry for this late v2 due to a long vocation.
kernel/locking/mutex.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 2fede72b6af5..2f654cfb10d9 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -351,13 +351,14 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
{
bool ret = true;
- rcu_read_lock();
while (__mutex_owner(lock) == owner) {
/*
* Ensure we emit the owner->on_cpu, dereference _after_
- * checking lock->owner still matches owner. If that fails,
- * owner might point to freed memory. If it still matches,
- * the rcu_read_lock() ensures the memory stays valid.
+ * checking lock->owner still matches owner. And we already
+ * disabled preemption which is equal to the RCU read-side
+ * crital section in optimistic spinning code. Thus the
+ * task_strcut structure won't go away during the spinning
+ * period
*/
barrier();
@@ -377,7 +378,6 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner,
cpu_relax();
}
- rcu_read_unlock();
return ret;
}
--
2.27.0
Powered by blists - more mailing lists