All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, will@kernel.org, oleg@redhat.com,
	tglx@linutronix.de, linux-kernel@vger.kernel.org,
	bigeasy@linutronix.de, juri.lelli@redhat.com,
	williams@redhat.com, bristot@redhat.com, longman@redhat.com,
	jack@suse.com
Subject: Re: [PATCH 5/5] locking/percpu-rwsem: Remove the embedded rwsem
Date: Mon, 18 Nov 2019 11:53:04 -0800	[thread overview]
Message-ID: <20191118195304.b3d6fg4jmmj7kmfh@linux-p48b> (raw)
In-Reply-To: <20191113102855.925208237@infradead.org>

On Wed, 13 Nov 2019, Peter Zijlstra wrote:
>@@ -54,23 +52,23 @@ static bool __percpu_down_read_trylock(s
> 	 * the same CPU as the increment, avoiding the
> 	 * increment-on-one-CPU-and-decrement-on-another problem.

Nit: Now that you've made read_count more symmetric, maybe this first
paragraph can be moved down to __percpu_rwsem_trylock() reader side,
as such:

	/*
	 * Due to having preemption disabled the decrement happens on
	 * the same CPU as the increment, avoiding the
	 * increment-on-one-CPU-and-decrement-on-another problem.
	 */
	preempt_disable();
	ret = __percpu_down_read_trylock(sem);
	preempt_enable();

> 	 *
>-	 * If the reader misses the writer's assignment of readers_block, then
>-	 * the writer is guaranteed to see the reader's increment.
>+	 * If the reader misses the writer's assignment of sem->block, then the
>+	 * writer is guaranteed to see the reader's increment.

...

> bool __percpu_down_read(struct percpu_rw_semaphore *sem, bool try)
> {
> 	if (__percpu_down_read_trylock(sem))
>@@ -89,20 +156,10 @@ bool __percpu_down_read(struct percpu_rw
> 	if (try)
> 		return false;
>
>-	/*
>-	 * We either call schedule() in the wait, or we'll fall through
>-	 * and reschedule on the preempt_enable() in percpu_down_read().
>-	 */
>-	preempt_enable_no_resched();
>-
>-	/*
>-	 * Avoid lockdep for the down/up_read() we already have them.
>-	 */
>-	__down_read(&sem->rw_sem);
>-	this_cpu_inc(*sem->read_count);
>-	__up_read(&sem->rw_sem);
>-
>+	preempt_enable();
>+	percpu_rwsem_wait(sem, /* .reader = */ true );
> 	preempt_disable();
>+
> 	return true;
> }
> EXPORT_SYMBOL_GPL(__percpu_down_read);

Do we really need to export symbol here? This function is only called
from percpu-rwsem.h.

>@@ -117,7 +174,7 @@ void __percpu_up_read(struct percpu_rw_s
> 	 */
> 	__this_cpu_dec(*sem->read_count);
>
>-	/* Prod writer to recheck readers_active */
>+	/* Prod writer to re-evaluate readers_active_check() */
> 	rcuwait_wake_up(&sem->writer);
> }
> EXPORT_SYMBOL_GPL(__percpu_up_read);
>@@ -137,6 +194,8 @@ EXPORT_SYMBOL_GPL(__percpu_up_read);
>  * zero.  If this sum is zero, then it is stable due to the fact that if any
>  * newly arriving readers increment a given counter, they will immediately
>  * decrement that same counter.
>+ *
>+ * Assumes sem->block is set.
>  */
> static bool readers_active_check(struct percpu_rw_semaphore *sem)
> {
>@@ -160,23 +219,22 @@ void percpu_down_write(struct percpu_rw_
> 	/* Notify readers to take the slow path. */
> 	rcu_sync_enter(&sem->rss);
>
>-	__down_write(&sem->rw_sem);
>-
> 	/*
>-	 * Notify new readers to block; up until now, and thus throughout the
>-	 * longish rcu_sync_enter() above, new readers could still come in.
>+	 * Try set sem->block; this provides writer-writer exclusion.
>+	 * Having sem->block set makes new readers block.
> 	 */
>-	WRITE_ONCE(sem->readers_block, 1);
>+	if (!__percpu_down_write_trylock(sem))
>+		percpu_rwsem_wait(sem, /* .reader = */ false);
>
>-	smp_mb(); /* D matches A */
>+	/* smp_mb() implied by __percpu_down_writer_trylock() on success -- D matches A */
                                               ^^^
					       write
...

>--- a/kernel/locking/rwsem.h
>+++ b/kernel/locking/rwsem.h
>@@ -1,12 +0,0 @@
>-/* SPDX-License-Identifier: GPL-2.0 */
>-
>-#ifndef __INTERNAL_RWSEM_H
>-#define __INTERNAL_RWSEM_H
>-#include <linux/rwsem.h>
>-
>-extern void __down_read(struct rw_semaphore *sem);
>-extern void __up_read(struct rw_semaphore *sem);
>-extern void __down_write(struct rw_semaphore *sem);
>-extern void __up_write(struct rw_semaphore *sem);

This is a nice side effect.

Thanks,
Davidlohr

  reply	other threads:[~2019-11-18 19:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 10:21 [PATCH 0/5] locking: Percpu-rwsem rewrite Peter Zijlstra
2019-11-13 10:21 ` [PATCH 1/5] locking/percpu-rwsem, lockdep: Make percpu-rwsem use its own lockdep_map Peter Zijlstra
2019-11-15 20:39   ` Davidlohr Bueso
2020-01-08  1:33     ` [PATCH] locking/percpu-rwsem: Add might_sleep() for writer locking Davidlohr Bueso
2020-01-08  1:33       ` Davidlohr Bueso
2020-02-11 12:48       ` [tip: locking/core] " tip-bot2 for Davidlohr Bueso
2019-11-13 10:21 ` [PATCH 2/5] locking/percpu-rwsem: Convert to bool Peter Zijlstra
2019-11-13 10:21 ` [PATCH 3/5] locking/percpu-rwsem: Move __this_cpu_inc() into the slowpath Peter Zijlstra
2019-11-13 10:21 ` [PATCH 4/5] locking/percpu-rwsem: Extract __percpu_down_read_trylock() Peter Zijlstra
2019-11-18 16:28   ` Oleg Nesterov
2019-11-13 10:21 ` [PATCH 5/5] locking/percpu-rwsem: Remove the embedded rwsem Peter Zijlstra
2019-11-18 19:53   ` Davidlohr Bueso [this message]
2019-11-18 23:19     ` Davidlohr Bueso
2019-12-17 10:45       ` Peter Zijlstra
2019-12-17 10:35     ` Peter Zijlstra
2019-11-18 21:52   ` Waiman Long
2019-12-17 10:28     ` Peter Zijlstra
2019-11-19 13:50   ` Waiman Long
2019-11-19 15:58     ` Oleg Nesterov
2019-11-19 16:28       ` Waiman Long
2019-12-17 10:26       ` Peter Zijlstra
2019-12-17 10:28         ` Peter Zijlstra
2019-11-15 17:14 ` [PATCH 0/5] locking: Percpu-rwsem rewrite Juri Lelli

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=20191118195304.b3d6fg4jmmj7kmfh@linux-p48b \
    --to=dave@stgolabs.net \
    --cc=bigeasy@linutronix.de \
    --cc=bristot@redhat.com \
    --cc=jack@suse.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=williams@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.